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COMMAND  FLIGHT  PATH  DISPLAY  PROGRAM 
PHASE  I  and  II 

FINAL  REPORT 


1 .0  INTRODUCTION 

The  Coamaod  Flight  Path  Display  (CFPD)  program  is  a  special  focus 
program  under  the  Aircraft  Technology,  6.2  Exploratory  Development  Block. 
The  purpose  of  the  program  is  to  develop  a  totally  integrated  pictorial 
aircraft  display  system  and  evaluate  the  concept  by  actual  flight  test 
consisting  of  take  off,  climb,  cruise/navigation,  approach  and  landing, 
with  and  without  visible  real  world  contact.  If  the  results  of  the  concept 
evaluation  warrant  continuation,  then  the  procedure  would  be  repeated  for 
tactical  operation  in  an  operational  aircraft. 


1.1  This  Final  Report  covers  Phase  I  and  Phase  II  of  the  CFPD  program. 
Phase  I  consisted  of  the  development  of  the  Command  Flight  Path  Display 
flight  test  system  and  Phase  II  was  the  actual  Flight  Test  Operation  of 
the  system  including  the  evaluation  of  the  CFPD  concept  by  analysis  of 
flight  test  recorded  data. 


1.2  On  20  April  1982,  a  meeting  was  held  with  the  Naval  Air  Systems  Command 
(KAVAIRSYSCOH),  the  Naval  Air  Development  Center  (KADC),  and  principals 
from  Systems  Associates,  Inc.  of  California,  Resource  Management  Systems 
Division  (SAI/RMS),  at  which  time  authorisation  was  given  to  SAI/RMS  to 
proceed  with  arrangements  to  initiate  Phase  I  of  the  CFPD  program.  It 
was  agreed  that  the  program  would  utilise  the  O.S.  Air  Force  KC  131H  Total 
In-Flight  Simulator  (TIFS)  aircraft  located  at  Arvin/Calspan  for  installation 
and  flight  testing  of  the  CFPD  system  as  recommended  by  SAI/RMS,  and  including 
the  services  of  Intermetrics,  Inc.  to  develop  the  required  display  software. 

1.3  On  23  April  1982,  arrangements  were  made  by  SAI/RMS  for  the  program 
kick-off  meeting  for  Phase  I  which  was  held  at  Arvin/Calspan  in  Buffalo, 
New  York,  on  5  May  1982.  Responsibilities  were  assigned  as  follows. 

a.  SAI/RMS  would: 

1.  Define  detailed  program  objectives  and  requirements  concerning 
the  CFPD  concept  and  functional  design  of  the  system  to 
produce  the  displays. 

2.  Through  a  subcontract  to  Intermetrics,  define,  produce 
and  document  all  software  in  the  host  processor  and  the 
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display  generator  except  that  associated  with  definition 
of  the  airplane  state  as  measured  by  the  sensors. 

3.  Assure  that  software  delivery  was  compatible  with  overall 
program  milestones. 

4.  Define  the  CFPD  evaluation  flight  test  objectives  and  a 
suitable  flight  test  program. 

5.  Analyze  the  flight  test  data  and  define  the  final  system 
design  to  ensure  its  adequacy  for  subsequent  NATC  evaluation. 

6.  Document  the  flight  test  results. 

b.  Intermetrics,  Inc.  would: 

1.  Develop  the  algorithms  for  the  generation  of  the  CFPD,  current 
HUD  symbology,  and  display  of  WAD  symbology  on  the  Evans 
and  Sutherland  PS-300  display  generator  system. 

2.  Prepare  the  software  specifications  for  the  PDP-11  computer 
and  the  PS-300. 

3.  Coordinate  the  PDP-11  and  PS-300  software  specifications 
with  the  Calspan  sensor  data  software  specifications  and 
prepare  a  total  system  software  specification. 

4.  Define  the  sensor  data  input  requirements  for  the  PDP-11 
computer  jointly  with  Calspan. 

5.  Develop  the  software  for  the  PS- 300. 

6.  Develop  the  software  for  the  PDP-11  as  it  relates  to  the 
PS-300. 

7.  Software  checkout  for  the  total  system  jointly  with  Calspan. 

8.  Specify  the  recording  software  requirements  for  the  concept 
evaluation  flight  test  as  defined  by  SAI/RMS. 

9.  Reduce  the  recorded  data  from  the  evaluation  flight  tests 
as  specified  by  SAI/RMS. 

10.  Provide  software  support  during  flight  test. 

11.  Provide  final  report  and  software  documentation. 

c.  Arvin/Calspan  would: 

1.  Prepare  software  specifications  for  sensor  data  conversion 
for  PDP-11  inputs,  working  in  conjunction  with  Intermetrics. 
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Establish  sensors  and  software  required  to  provide  data 
inputs  to  the  PDP-11. 

Define  system  integration  and  installation  requirements. 
Design  the  system  installation. 

Fabricate  the  system  interconnections. 

Install  the  system. 

Checkout  of  the  total  system  via  a  complete  end  to  end  systems 
test,  jointly  with  Intermetrics . 

Provide  Flight  Test  Operation  support  and  obtain  AF  approval 
for  flight  test. 

Provide  Flight  Test  Aircraft  and  System  maintenance  support 
except  for  SAI/RMS  and  Navy  GFE  equipment. 

Provide  pilots  for  the  concept  evaluation  flight  test. 

Provide  a  "quick  look"  capability  for  evaluation  of  flight 
data  after  each  flight  from  the  TIFS  recording  system,  if 
required. 

Provide  processed  data  tapes  for  subsequent  analysis,  if 
required. 

Document  all  external  meetings ,  phone  conversations,  con¬ 
ferences,  etc.,  and  submit  to  KADC,  FDL,  and  SAI/RMS. 

Notify  NADC,  FDL,  and  SAI/RMS  of  all  critical  situations 
existing  or  probable  as  soon  as  possible. 

Design  and  implement  provisions  for  WAD. 

Provide  input  for  final  report. 


1.4  It  is  important  to  point  out  that  NAVAIRSYSCOM ,  NAVAIR  03B,  at  the 
20  April  meeting,  established  the  deadline  of  28  February  1983,  for  proof 
of  concept  by  actual  flight  test  of  the  CFPD.  That  deadline  was  met  by 
conducting  the  first  flight  test  of  the  CFPD  on  9  February  1983,  further 
flight  test  on  10  February  1983,  and  by  Intermetrics'  first  data  reduction 
results  which  were  provided  on  17  February  1983,  just  9.5  months  after 
start  up  and  ten  days  before  the  deadline. 

1.5  Although  many  problems  were  encountered  during  the  execution  of  Phases 
1  and  II,  the  competence  of  the  entire  program  team  overcame  these  obstacles, 
and  the  program  objectives  were  completely  achieved. 
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1.6  The  subject  report  is  divided  into  Sections  2.0  through  6.0. 

Section  2.0  consists  of  a  general  executive  summary  of  the  overall 
CFPD  program  including  the  major  results  achieved,  conclusions  drawn  and 
recommendations  for  continued  effort. 

Section  3.0  describes  Phase  I  with  a  detailed  technical  discussion 
of  the  CFPD  system  design.  This  section  was  to  include  the  Intermetrics 1 
report  describing  the  development  of  the  display  software,  and  the  Calspan 
report  covering  the  sensor  conversion  software,  the  CFPD  equipment  hardening, 
the  installation  of  the  system  in  the  TIFS  aircraft,  and  the  ground  simulation 
system  to  accommodate  the  CFPD  test  program  requirements. 

Section  4.0  covers  the  Phase  II  Flight  Test  procedures,  including 
the  ground  simulation,  the  actual  in  flight  operation,  and  the  data  recording 
techniques. 

Section  5.0  describes  the  observations  resulting  from  the  reduction 
of  the  recorded  ground  simulation  and  in  flight  data. 

Section  6.0  consists  of  a  group  of  appendices  covering  detailed 
specific  data  relative  to  the  program  schedule,  cost,  iseetings,  pilot  cosnsents, 
installation  photographs,  and  flight  test  plots. 


2.0  SUMMARY  AMU  CONCLUSIONS 


2.1  Command  Flight  Path  Display  Program  Concept  Definition 

The  Command  Flight  Path  Display  Concept  is  defined  as  a  pictorial 
presentation  of  totally  integrated  real  world  visual  cues  which  provides 
the  pilot  of  an  aircraft  with  the  following  information: 

Orientation  -  Where  am  I  and  what  am  I  doing? 

Director  -  What  should  1  do  and  when? 

Quantitative  -  How  am  I  doing? 


All  three  categories  of  information  are  presented  relative  to  the 
real  world  vertical  plane  on  a  cathode  ray  tube  called  the  Vertical  Situation 
Indicator  (VSI),  and  relative  to  the  real  world  horizontal  plane,  on  a 
cathode  ray  tube  called  the  Horizontal  Situation  Indicator  (ESI). 

The  Vertical  Situation  Display  Format  should  be  displayed  on  a  HUD(VSI) 
because  this  is  one  of  the  major  requirements  of  the  overall  concept. 
It  can  also  be  displayed  on  a  panel  mounted  CRT  VSI.  In  both  cases  the 
display  format  consists  of  the  following  three  independent  elements  (Figure 
2-1). 

a.  A  dynamic  earth  plane  or  "contact  analogue"  composed  of  external 
reference,  linear  perspective,  texture,  size  and  shape,  and 
motion  parallax  visual  cues,  with  the  capability  of  angular 
and  linear  displacement  relative  to  all  three  axes. 

b.  A  dynamic  flight  path  composed  of  the  same  visual  cues  as  the 
contact  analogue  and  with  the  same  six  degrees  of  freedom. 

c.  A  command  velocity  indicator  displayed  as  a  three  dimensional 
aircraft  located  by  pilot  selection,  either  to  the  left,  right 
or  center,  placed  above  or  below  relative  to  the  flight  path, 
and  with  the  capability  of  changing  in  size  and  perspective 
as  the  pilot  alters  his  formation  position. 

The  Horizontal  Situation  Display  Format  is  always  displayed  on  the 
HSI  which  should  be  oriented  to  the  horizontal  plane.  The  format  consists 
of  the  following  elements  (Figure  2-2). 

a.  A  topographical  map  or  tactical  plot  depending  upon  the  type 
of  mission  being  conducted  is  provided  covering  the  operational 
area  of  the  aircraft  including  terrain  characteristics,  potential 
obstacles,  navigational  aid  locations,  operational  bases,  destina¬ 
tions,  and  targets. 

b.  A  geographical  Command  Flight  Path  indicating  the  proposed 
or  altered  flight  plan  including  all  segments  and  vay  points, 
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Figure  2-1 

CFPD  Vertical  Situation  Indicator 
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Che  aircraft  shadow  representing  present  position  relative  to 
the  flight  path,  an  indication  of  wL?re  the  aircraft  should 
be  on  the  flight  path,  and  an  ellipse  which  indicates  range 
renaining  relative  to  present  power,  altitude  and  velocity. 
(This  ellipse  was  not  included  in  the  TIFS  display  during  Phase 
II,  but  will  be  in  Phase  III.) 

In  the  Phase  II  test  program  both  displays  were  included,  but  emphasis 
was  placed  on  the  Vertical  Situation  Display  with  the  RSI  providing  only 
the  geographical  Command  Flight  Path  and  the  aircraft  position  relative 
to  the  Command  Position.  The  program  objective  was  more  directed  to  determin¬ 
ing  the  ability  of  the  pilot  to  fly  the  aircraft  effectively  under  IFR 
conditions,  particularly  with  respect  to  take-off  and  landing,  and  normal 
flight  operations  rather  than  tactical  missions.  The  above  in  brief,  describes 
the  overall  basic  Command  Flight  Path  Concept.  It  must  be  stressed  that 
all  of  the  elements  of  the  VSI  display  had  to  be  included  because  all  of 
the  elements  are  necessary  to  provide  an  integrated  display  and  present 
the  required  information. 


2.1.1  Cosnund  Flight  Path  Display  Program  Objectives 

The  overall  objective  was  to  prove  the  validity  of  the  Command  Flight 
Path  Display  concept  which  consists  of  a  totally  integrated  pictorial  presenta¬ 
tion  of  the  fundamental  information  necessary  to  effectively  perform  all 
of  the  normal  basic  flight  operations  with  and  without  reference  to  the 
real  world. 

The  specific  objectives  were: 

a.  To  demonstrate  during  actual  flight  that  the  CFPD  is  in  fact 
a  truly  integrated  display  which  does  provide  the  pilot  with 
adequate  information  to  execute  take-off,  climb,  cruise/navigation, 
approach  and  landing,  without  reference  to  conventional  parametric 
displays,  or  the  real  world. 

b.  To  establish  that  pilot  performance  with  the  CFPD  is  enhanced 
demanding  minimal  concentration  on  the  display,  minimising  inadver¬ 
tent  departures,  and  requiring  minimal  training  time,  both  initially 
and  for  maintaining  flight  proficiency,  as  compared  to  performance 
utilising  standard  symbolic  displays. 

c.  To  prove  that  the  electronic  system  required  to  generate  the 
CFPD  can  be  achieved  by  modifying  current  aircraft  display  and 
control  systems  through  the  utilisation  of  computer  graphics 
picture  processing  techniques. 


2.1.2  Contract  Arrangements 

The  CFPD  Program  has  been  funded  by  the  D.S.  Navy  through  the  Naval 
Air  Systems  Command  (NAVAIRSTSCOM)  and  the  Naval  Air  Development  Center 
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(NADC),  Warminster,  PA.  Funds  were  transferred  by  interservice  funding 
documents  to  the  U.S.  Air  Force,  Wright  Patterson  Air  Force  Ease,  for  applica¬ 
tion  to  an  existing  Air  Force  Contract  with  Arvin/Calspan  Advanced  Technology 
Center,  Buffalo,  MY.  Under  this  contract,  vF33615-79-C-3618 ,  Arvin/Calspan 
provides  continuing  test,  evaluation  and  other  technical  services  to  the 
U.S.  Air  Force  and  the  U.S.  Navy. 


Systems  Associates,  Inc.  of  California  was  contracted  by  Arvin/Calspan, 
under  subcontract  #S-82-03 ,  to  develop,  integrate  and  evaluate  the  CFPD 
and  to  provide  subcontract  management  of  software  and  hardware  vendors. 
Intermetrics,  Inc.,  Cambridge,  Massachusetts,  provided  engineering  and 
software  services  under  Subcontract  No.  SAI-83-01.  Engineering  services 
were  also  purchased  from  Evans  and  Sutherland,  Salt  Lake  City,  Utah,  by 
SAI/RMS  purchase  order. 


Equipment  was  provided  by  the  Navy  or  purchased  by  Arvin/Calspan, 
and  SAI/RMS.  Arvin/Calspan  also  provided  engineering  and  installation 
services  and  the  flight  crews  (safety  pilots)  during  evaluation  flights 
of  the  CFPD  in  the  USAF  NC  131H  (TIFS)  aircraft. 


cl 


2.1.3  Phase  I  -  Tasks 

In  accordance  with  the  subject  contract,  the  tasks  performed  under 
Phase  I  were  as  follows: 

I«fe  1 


b. 

c. 

d. 


e. 


f. 


The  definition  of  the  overall  project  objectives  and  the 
requirements  to  meet  these  goals. 

The  definition  of  the  CFPD  concept. 

The  functional  design  of  the  system  to  produce  the  CFPD. 
Establishswnt  of  the  project  milestones,  coordination  of 
the  Iatermetrica  subcontract,  and  monitoring  of  the  project 
schedule,  particularly  software  delivery. 

The  definition  of  the  CFPD  Concept  Evaluation  Flight  Test 
objectives  and  the  design  of  a  suitable  flight  test  program. 
The  preparation  of  the  documentation  covering  Tasks  1,  2 
and  3. 


Task  2 


SAI/RMS  will  provide  engineering  assistance  for  system  integration 
and  installation  requirements. 
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Task  3 


SAI/RMS  will  provide  for  the  purchase  of  the  following  engineering 
services  from  Intermetrics,  Inc.: 


a.  Development  of  the  algorithms  for  the  generation  of  the 
CFPD,  current  HUD  symbology,  and  display  of  WAD  symbology 


■■  r.  v.  ^vv.-y.-gv1  v.  ?-,  —  »-.»- 


on  a  PS-300  Graphic  Display. 

b.  Preparation  of  the  software  specifications  for  the  PDP-11/44 
computer  and  the  PS-300. 

c.  Coordination  of  the  PS-300  and  PDP-11/ 44  software  specifications 
with  the  Calspan  sensor  data  software  specifications  and 

d.  Definition  of  the  sensor  data  input  requirements  for  the 
PDP-11/44  computer  jointly  with  Calspan. 

e.  Development  of  the  software  for  the  PS- 300. 

f.  Development  of  the  software  for  the  PDP-11/44  as  it  relates 
to  the  PS- 300. 

g.  Software  check-out  for  the  total  system  jointly  with  Calspan. 

h.  Definition  of  the  recording  requirements  for  the  CFPD  concept 
evaluation  flight  test. 

i.  Document  software  to  include  algorithms,  flow  diagrams, 
definition  of  terms,  etc.,  as  well  as  the  actual  coding. 


2.1.4  Phase  II  -  Tasks 

The  tasks  performed  under  Phase  II  were  as  follows: 

Task  1  -  Working  with  Intermetrics,  check  out  the  overall  display 
system  utilizing  the  ground  flight  simulator  capability  of  the 
TIFS  aircraft.  Minor  modifications  of  the  displays  will  be 
made  during  this  effort. 

Task  2  -  Brief  the  evaluation  pilots  before  and  during  the  flight 
simulator  runs  and  conduct  flight  tests  as  indicated  in  the 
Flight  Test  Plan  Schedule. 

Task  3  -  Modify  the  aircraft  by  replacing  the  VSI  with  the  Hughes 
AIDS  HUD  and  conduct  ground  simulation  and  check  out  system. 

Task  4  -  Conduct  ground  simulation  runs  followed  by  flight  tests 
as  indicated  in  the  Flight  Test  Plan  Schedule. 

Task  5  -  Reduce  flight  data  and  prepare  a  final  report  of  the 
Coommnd  Flight  Path  Display  concept  evaluation. 


2.2  Development  of  the  Command  Flight  Path  Display  Flight  Test  System 

At  the  start  up  of  Phase  I  it  was  jointly  agreed  by  KADC,  SAI/RMS, 
and  Intermetrics  that  the  major  component  of  the  CFPD  flight  test  system 
would  be  the  Evans  and  Sutherland  PS-300  general  purpose  interactive  computer 
graphic  system.  It  was  also  agreed  that  in  order  to  accomplish  the  type 
of  flight  test  required  to  prove  the  CFPD  concept,  an  inertial  navigation 
system  (IRS)  would  be  installed  in  the  TIFS  aircraft. 

Using  the  above  as  a  point  of  departure,  many  significant  changes 
had  to  be  made  to  accomplish  the  program  objectives  while  maintaining 
the  schedule  within  the  proposed  budget. 
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Purchase  orders  for  Che  aajor  hardware  items  were  prepared  by  KADC. 
Calspan  placed  on  order  Che  lab  peripheral  accelerator  (LPA-llK)  and  chose 
components  necessary  Co  fabricate  the  input/output  interface  chassis. 
The  software  interface  specifications  were  determined  and  agreed  upon  by 
Intermetrics  and  Calspan.  SAI/RMS  investigated  available  CRTs  and  initiated 
discussions  with  Xytron,  Inc.,  manufacturer  of  the  standard  PS-300  display. 
The  high  writing  speed  of  the  PS-300  and  available  cockpit  space  dictated 
custom  displays  be  built.  In  addition,  the  Naval  Air  Systems  Command  required 
the  use  of  the  Hughes  AIDS  Head-Op  Display  as  part  of  the  flight  test. 
The  compatibility  of  the  PS-300  and  the  HOD  as  well  as  the  HUD  availability 
were  in  question. 

Delays  began  to  surface  quickly.  Purchase  orders  for  the  government 
furnished  equipment  were  not  received  by  the  manufacturers  to  allow  sufficient 
lead  time  to  meet  program  delivery  requirements.  The  INS  from  the  Air 
Force  Flight  Dynamics  Lab  turned  out  to  be  unavailable  and  a  search  for 
another  unit  started.  The  Air  Force  requirement  for  ruggediration  and 
vibration  testing  of  the  commercial  equipment  prior  to  installation  in 
TIFS  added  a  further  squeeze  on  available  time. 

Discussiona  were  initiated  with  Evans  and  Sutherland  on  ruggedization 
of  the  PS-300.  Ruggedization  of  the  unit  by  Evans  and  Sutherland  personnel, 
as  it  was  built  would  save  valuable  time.  Initial  response  was  favorable 
but  Evans  and  Sutherland  management  would  not  consent  to  delivery  of  other 
than  a  standard  unit.  They  would  provide  a  kit  that  could  be  used  for 
ruggedization  and  engineering  services  but  would  not  modify  the  unit  them¬ 
selves.  As  a  result,  a  second  PS-300  was  needed  to  allow  software  development 
to  continue  uninterrupted  while  the  unit  to  be  installed  in  the  aircraft 
was  ruggedized. 

Magnetic  tape  recording  equipment  scheduled  for  use  in  the  CFPD 
system  began  to  develop  reliability  problems.  A  search  for  alternate 
equipment  by  SAI/RMS  resulted  in  a  purchase  order  from  Calspan  for  a  recording 
system  from  Western  Peripherals. 

Serious  doubts  began  to  develop  concerning  the  PS- 300  capabilities 
for  the  CFPD  application.  Software  engineers  were  concerned  about  the 
ability  of  the  PS-300  to  update  the  required  information  at  the  required 
rate.  Modifications  to  the  PS-300  firmware  were  necessary  and  resulted 
in  custom  firmware  that  increased  the  processing  capability  of  the  unit. 

NADC  chose  the  F-18  standard  symbology  for  use  as  the  comparative 
symbology  during  the  flight  test.  CFPD  software  development  at  Intermetrics 
and  sensor  software  development  at  Calspan  continued.  The  PS- 300-HUD 
interface  problem  was  solved  but  required  a  502  reduction  in  writing  speed 
of  the  PS- 300. 

A  partial  delivery  of  the  first  PS- 300  to  Intermetrics  was  made 
on  September  7,  1982.  Installation  by  Evans  and  Sutherland  representatives 
was  not  completed  until  September  14.  Calspan  submitted  the  Class  II  Modifica¬ 
tion  Part  I  to  the  Air  Force  and  released  purchase  orders  for  the  Xytron 
displays,  magtape  recorder,  and  the  second  PS-300.  An  inertial  navigation 
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system  was  located  by  NADC  and  delivered  to  Calspan  on  October  3,  1983. 

Mr.  Hoover  continued  discussions  with  Dr.  Dave  Evans  of  Evans  and 
Sutherland  concerning  ruggedization  of  the  PS- 300.  Evans  and  Sutherland 
agreed  to  provide  a  unit  prepared  for  installation  of  a  special  back  plane 
and  edge  connectors  and  to  do  the  installation  of  the  retrofit  kit  at  Calspan. 
Sensor  software  was  completed  and  delivered  to  Intermetrics  for  integration 
with  the  CFPD  software.  A  flight  plan  was  prepared  and  incorporated  into 
a  flight  test  program  prepared  by  SAI/R11S. 

Software  development  was  completed  and  real  time  testing  was  accom¬ 
plished  at  Intermetrics.  The  computer  and  accessories  were  then  shipped 
to  Calspan  for  system  integration  test.  Evans  and  Sutherland  provided 
a  pre-production  PS-300  with  a  modified  csrd  cage  that  eliminated  the  require¬ 
ment  for  installing  a  retrofit  kit.  All  commercial  CFPD  equipment  was 
hardened  followed  by  vibration  testing.  Results  of  the  test  were  submitted 
to  the  Air  Force  in  the  Class  II  Part  II  Modification. 

The  CFPD  System  equipment  was  then  installed  and  TIFS  was  prepared 
for  ground  simulation  and  testing. 


2.3  Flight  Test  of  the  Command  Flight  Path  Display/ Concept  Evaluation 
Flight  Test  Plan 

The  procedure  for  validating  the  CFPD  concept  consisted  of  comparing 
the  flight  performance  of  a  number  of  pilots  having  different  degrees  of 
experience,  while  flying  a  specific  flight  plan,  first  utilizing  a  slightly 
modified  current  F-18  discrete  symbol  display,  (Figures  2-3,  2-4  and  2-5) 
followed  by  flying  the  same  flight  plan  with  the  command  flight  path  integrated 
pictorial  display. 

The  measure  of  the  subject  test  pilots'  performance  was  to  be  based 
upon  the  number  and  magnitude  of  inadvertent  departures  from  the  prescribed 
flight  plan  which  were  recorded  relative  to  the  three  flight  axes  plus 
velocity  control,  when  flying  each  type  of  display. 

These  procedures  were  performed  first  with  VSI  and  ESI  CRT  displays 
with  the  test  cockpit  windows  completely  covered  with  translucent  material 
to  simulate  zero-zero  conditions,  and  then  followed  by  replacing  the  VSI 
with  the  Hughes  AIDS  HUD  and  repeating  the  procedures  under  acceptable 
actual  minimal  weather  conditions. 

The  flight  test  pattern  consisted  of  a  modified  instrument  flight 
training  pattern  composed  of  a  series  of  interrelated  maneuvers  and  perform¬ 
ances  basic  to  normal  instrument  flight  rule  (IFR)  flight.  (Figure  2-6) 

The  entire  prescribed  flight  pattern  was  programmed  to  establish 
a  virtual  air  space  3000  feet  deep,  covering  approximately  27  square  miles 
with  a  perimeter  of  roughly  78.5  miles.  Since  the  pattern  segments  and 
way  points  were  fixed,  the  coordinates  could  be  oriented  relative  to  nr/ 
heading  and  barometric  level  selected.  By  initially  setting  the  IKS  at 
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Figure  2-6 
Flight  Test  Pattern 


0  Latitude,  0  Longitude  and  0  Altitude,  any  departure  froc  the  prescribed 
path  could  be  measured,  regardless  of  the  magnetic  heading  and  altitude 
flown.  The  selected  heading,  however,  which  was  decided  by  the  TIFS  safety 
pilots  was  a  cardinal  heading  and  prescribed  prior  to  any  operation  either 
for  ground  simulation  or  flight. 

The  procedure  to  initiate  the  flight  test  was  for  the  safety  pilots 
to  depart  Buffalo,  climb  to  6000  feet,  turn  to  the  prescribed  heading  at 
the  selected  test  area,  and  indicate  that  the  aircraft  was  in  position 
to  start  the  course.  The  only  reason  for  establishing  a  cardinal  heading 
was  to  make  it  easier,  when  using  the  F-18  symbology,  to  calculate  a  new 
heading  when  the  initial  heading  was  an  even  number. 

When  the  safety  pilot  gave  the  signal  that  the  aircraft  was  in  position, 
the  CFPD  engineer  initiated  the  flight  plan  by  bringing  up  the  F-1S  symbology. 
At  the  end  of  the  first  pattern,  if  the  evaluation  pilot  was  off  course, 
altitude  or  airspeed,  the  safety  pilot  would  take  over,  bring  the  aircraft 
back  into  position  and  notify  the  CFPD  engineer  that  he  was  ready  to  start 
the  second  pattern. 

The  geographical  starting  point  of  the  flight  test  pattern  was  reason¬ 
ably  close  to  the  Niagara  airport  because  upon  completion  of  flying  the 
prescribed  pattern,  each  evaluation  pilot  was  required  to  make  two  instrument 
landing  system  (ILS)  approaches  to  the  flare  point  at  Niagara,  first  with 
the  F-18  display  and  then  with  the  CFPD.  This  exercise  was  conducted  by 
having  the  TIFS  safety  pilots  bring  the  aircraft  to  an  approach  position 
outside  the  outer  marker,  engage  the  ILS  and  turn  the  control  over  to  the 
CFPD  engineer  and  the  evaluation  pilot. 

The  CFPD  was  programmed  to  portray  all  variations  in  the  flight 
patterns  and  required  no  external  information  relative  to  way  points. 
When  the  evaluation  pilot  was  flying  the  F-18  display,  the  external  navigation 
aids  to  provide  bearing  and  DME  for  the  way  points  were  not  available  because 
of  the  requirement  to  use  "virtual"  airspace.  In  view  of  this,  the  CFPD 
engineer  provided  the  evaluation  pilots  with  the  required  way  point  information. 

Upon  completion  of  the  above  phase  of  the  test  program,  the  aircraft 
was  modified  by  replacing  the  VSI  CRT  with  the  Hughes  AIDS  HUD. 

Following  the  HUD  display  check-out,  the  evaluation  pilots  repeated 
the  same  operations  performed  during  the  first  phase  of  the  test  program 
but  using  the  HUD  instead  of  the  VSI,  and  under  varying  VFR  and  IFR  conditions. 

Mr.  George  Hoover  was  the  first  pilot  to  fly  the  Command  Flight 
Path  Display  on  9  February  1983.  Satisfied  with  the  dynamics  of  the  display, 
he  requested  Mr.  Robert  Harper  fly  the  pattern  on  the  CFPD.  The  following 
day  Mr.  Harper  flew  patterns  on  both  the  CFPD  and  the  symbology  and  Mr. 
Victor  Cronauer  flew  a  partial  pattern  on  the  CFPD.  Hr.  Harper's  patterns 
served  as  a  baseline  for  performance  comparison  of  the  pilots  to  follow. 

The  remaining  pilots  who  participated  in  the  flight  test  program 
were  from  the  Naval  Air  Systems  Command,  the  Naval  Air  Development  Center, 


and  the  Naval  Air  Test  Center. 


A  breakdown  of  time  in  model  for  those  pilots  participating  in  the 
CFFD  flight  test  is  as  follows.  Data  on  all  participants  were  not  available. 


Total 


Pilot 

Hours 

Hours  bv  Tvoe 

T-34  T-2 

TA4 

A- 7 

11 

T38 

F/A18 

F4 

Lt  R.J.  O'Hanlon 

1800 

200 

1200 

20 

Lt  J.D.  Wetherbee 

1700 

150 

150 

1300 

85 

15 

LCDR  J.J.  Halters 

1275 

25  100 

100 

900 

CDR  F.  Ameel 

2758 

150 

2358 

176 

7 

65 

VADM  E.R.  Seymour  N/A 
CAPT  R.D.  Friichtenicht  N/A 

Data  recordings  were  made  as  part  of  the  flight  plan.  Departures 
in  all  three  axes  from  the  planned  flight  path  were  recorded  on  magnetic 
tape.  A  video  recording  of  the  VS1  display  presented  to  the  pilot  in  the 
evaluation  cockpit  was  taped.  TIFS  intercommunication  system  (ICS)  comments 
during  the  flight  tests  and  post  flight  debriefs  were  also  recorded.  All 
original  video  and  voice  tapes  were  delivered  to  the  Naval  Air  Development 
Center.  The  magnetic  tapes  of  recorded  flight  data  were  utilized  for  genera¬ 
tion  of  flight  test  plots. 


2.4  Program  Results 

In  general,  it  can  be  stated  that  each  task  proposed  for  Phase  I 
and  Phase  II  of  the  CFPD  program  was  successfully  accomplished,  on  schedule, 
and  within  the  limits  of  the  original  proposed  budget. 

The  significant  specific  results  achieved  were  as  follows: 

a.  The  CFPD  Flight  Test  System  was  developed  by  utilizing  off-the-shelf 
commercial  components  primarily  because  they  were  the  only  units 
capable  of  meeting  the  system  requirements  and  available  within 
the  timeframe  and  the  budget  limitations  of  the  program.  With 
special  ruggedizing  techniques  and  careful  installation  furnished 
by  Calspan,  the  system  (excluding  the  AIDS  HUD)  experienced 
no  failures  from  the  first  start  up  through  the  completion  of 
the  last  test  flight. 

b.  The  Flight  Test  of  the  CFPD  system  including  90  hours  of  ground 

simulation  and  20  hours  of  in  flight  operations  was  accomplished 
as  scheduled  with  only  one  flight  cancelled  due  to  inclement 
weather.  From  February  9,  1983,  to  April  20,  1983,  eleven 

flights  were  made  by  nine  evaluation  pilots  including  VADM  Seymour, 
COMMA VAIRSYSCOM,  and  Captain  Friichtenicht,  AIR  03.  Four  additional 
hours  were  flown  with  the  system  by  two  pilots  from  the  U.S. 


Naval  Test  Pilot  School  who  flew  only  for  syllabus  requirements 
because  the  Cal  span  X-22  was  down. 

c.  During  all  flight  tests  continuous  recordings  were  nade  of  three 
dimensional  position  data,  flight  path  referenced  position  data, 
and  altitude  and  lateral  deviations.  In  addition,  video  tapes 
of  the  VSI  were  recorded  along  with  TIFS  intercommunication 
system  (ICS)  audio  comments. 

d.  After  each  flight  the  debriefing  of  each  pilot  was  recorded 
on  audio  tape  and  then  transcribed.  These  are  included  in  this 
report  as  Appendix  D. 

e.  The  recorded  data  from  each  flight  were  identified  and  separated, 
then  coordinated  with  reference  and  timing  information,  and 
then  analyzed  to  establish  statistical  parameters  which  were 
then  utilized  to  draw  the  various  plots  to  demonstrate  the  actual 
performance  of  the  aircraft  at  any  point  along  the  flight  plan. 
Analyses  of  these  plots  coordinated  with  each  pilot's  comments 
from  the  ICS  and  debriefing  tapes  were  used  as  the  basis  for 
evaluating  the  CFPD  concept. 


2.5  Conclusions 

The  performance  plots  shown  in  Figures  5-1  through  5-6,  and  Appendix 
F,  provide  positive  evidence  that  the  flight  test  techniques  which  were 
used  to  evaluate  the  CFPD  concept  were  indeed  valid  because  the  information 
displayed  on  these  plots  is  a  truly  dynamic  presentation  of  actual  three 
dimensional  aircraft  operation.  This  method  of  evaluating  displays  by 
measuring  actual  performance  relative  to  required  performance  provides 
specific  answers  as  to  how  well  pilots  conduct  selected  missions,  rather 
than  just  recording  evaluating  pilots'  personal  opinions  of  how  the  displays 
should  be  altered.  As  pointed  out  in  Section  5.0,  by  comparing  performance 
achieved  with  one  display  vs.  another,  but  recorded  relative  to  a  command 
mission,  the  concept  of  paired  comparison  takes  on  a  new  meaning.  In  this 
instance,  instead  of  just  determining  that  one  display  is  better  than  another, 
it  is  easy  to  establish  whv  one  is  better. 


2.5.1  Conclusions  -  Program  Objectives 

In  view  of  the  above,  the  analyses  of  the  data  generated  the  following 
conclusions  relative  to  the  objectives  of  the  CFPD  program: 

a.  Objective  1  -  Flight  test  results  demonstrated  during  actual 
flight  that  the  CFPD  is  a  truly  integrated  display  which  does 
provide  the  pilot  with  adequate  information  to  execute  take-off, 
climb,  cruise/navigation,  approach  and  landing,  without  reference 
to  conventional  parametric  displays,  or  the  real  world. 


Objective  2  -  Analyses  of  the  operational  plots  fully  establish 
that  pilot  performance  with  the  CFPD  is  enhanced,  demanding 
minimal  concentration  on  the  display,  minimizing  inadvertent 
departures,  and  definitely  requiring  minimal  training  time  (total 
training  time  prior  to  flight  was  one  half  hour  with  the  CFPD), 
both  initially  and  for  maintaining  flight  proficiency,  as  compared 
to  performance  utilizing  standard  symbolic  displays. 

Objective  3  -  The  program  results  proved  that  the  electronic 
system  required  to  generate  the  CFPD  can  be  achieved  by  relatively 
minor  modifications  to  the  aircraft  display  and  control  systems 
currently  installed  in  operational  aircraft,  and  by  utilizing 
computer  graphics  picture  processing  techniques. 


2.5.2  Conclusions  -  Command  Flight  Path  Display  Concept 

In  addition  to  meeting  the  objectives  of  the  program,  considerable 
knowledge  was  gained  relative  to  the  fundamental  concepts  of  the  Command 
Flight  Path  Display.  The  significant  conclusions  are  as  follows: 

a.  The  concept  of  continuous  command  information  is  perhaps  one 
of  the  most  significant  innovations  that  the  CFPD  format  provides 
to  man-machine  systems  displays.  By  having  this  information 
available,  the  necessity  for  memorizing  each  segment  of  the 
mission  flight  plan,  or  even  referring  to  a  navigation  chart, 
is  elisdnated.  This  situation  became  evident  during  the  actual 
flight  test  because  the  evaluation  pilots  either  did  not  attempt 
to  memorize  the  flight  test  plan,  or  they  could  not  remember 
each  maneuver  while  occupied  with  controlling  the  aircraft. 
Review  of  the  ICS  voice  tapes  clearly  establishes  that  each 
pilot,  while  flying  the  symbology  format,  had  to  be  coached 
by  a  second  pilot  in  the  right  seat  of  the  evaluation  cockpit 
with  regard  to  each  upcoming  event  of  the  flight  plan.  If  the 
evaluation  pilot  had  not  been  informed  of  each  required  change 
to  be  made,  he  would  have  been  required  to  read  the  flight  plan 
chart  which,  in  turn,  would  have  seriously  altered  his  scan 
pattern  and  the  inadvertent  departures  would  have  been  far  greater 
than  those  which  were  actually  recorded. 

In  contrast  to  this  procedure,  no  coaching  relative  to  the  flight 
plan  was  necessary  when  the  evaluation  pilot  was  flying  the 
CFPD  format  because  the  required  information  was  inherent  in 
the  display. 

The  necessity  for  presenting  anticipatory  cues,  which  the  CFPD 
provides,  becomes  much  more  critical  during  tactical  operations 
requiring  very  exacting  flight  plans  such  as  terrain  fol lotring, 
even  under  VFR  conditions,  and  are  absolutely  mandatory  under 
IFR  conditions.  It  is  important  to  understand  that  this  type 
of  command  information  does  not  exist  in  current  tactical  aircraft 
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displays 


Another  concept  inherent  in  the  CFPD  format  is  the  requirement 
for  an  integrated  display  in  lieu  of  combined  discrete  symbols. 
Since  the  word  "symbol",  by  definition,  is  "something  that  stands 
for  or  represents  another  thing",  it  follows  that  symbols  require 
interpretation,  and  interpretation,  in  turn,  requires  a  learning 
process  followed  by  mental  integration. 

If,  as  an  alternative,  the  display  consists  of  an  integration 
of  real  world  visual  cues,  no  learning  process  or  interpretation 
should  be  required  and  the  information  present  in  the  display 
would  be  acquired  through  differentiation* 

Examination  of  the  performance  plots  of  each  evaluation  pilot 
very  definitely  established  four  significant  differences  between 
the  F-18  type  symbology  and  the  CFPD,  which  substantially  influenced 
the  obvious  differences  in  performance. 

1.  Essentially  no  learning  process  or  interpretation  was  required 
by  the  evaluation  pilots  when  flying  the  CFPD  with  the  exception 
of  "flashing"  the  lead  aircraft  to  indicate  excessive  velocity , 
and  which  will  be  replaced  by  real  world  visual  cues  during 
the  next  phase  of  the  program.  Each  pilot  saw  the  CFPD 
format  for  the  first  time  on  the  evening  before  his  evaluation 
flight,  and  flew  the  format  in  the  ground  simulator  for 
only  one  half  hour  prior  to  his  first  actual  flight.  Each 
pilot,  on  the  other  hand,  had  flown  a  considerable  number 
of  hours  with  similar  versions  of  the  symbology  format. 

2.  Another  aspect  of  the  comparison  of  discrete  symbology  relative 
to  integrated  visual  displays  which  was  examined  was  the 
effect  of  lag  time  inherent  in  the  system.  During  the  simula- 
tion  phase,  it  became  apparent  that  the  data  processing 
interface  between  the  host  computer  and  the  picture  processor 
had  a  lag  time  of  approximately  200  to  300  milliseconds. 
Investigation  of  the  probable  cause  of  this  delay  revealed 
that  the  only  interface  available  (non-real  time  DMR-1 1 
DECnet)  was  the  primary  contributor  to  the  system  latency 
problem.  In  view  of  this  situation,  there  was  some  concern 
by  the  Calspan  pilots  that  such  a  lag  time  might  negate 
the  validity  of  the  flight  test  results,  and  in  fact,  during 
debriefing  sessions,  some  pilots  indicated  that  the  lag 
time  was  very  noticeable  when  flying  the  symbology,  but 
not  apparent  when  f Ivina  the  CFPD. 

Since  both  display  formats  were  driven  by  the  same  data 
processing  system  we  can  only  conclude  that  lag  time  in 
displays  are  amplified  when  discrete  symbols  are  utilized, 
but  minimized  with  integrated  real  world  visual  cue  displays. 
(It  has  been  learned  just  recently  that  a  real  time  interface 
is  now  available.) 


3.  The  third  important  difference  between  the  symbolic  format 
and  the  CFPD  relate*  to  disorientation.  Several  of  the 
evaluation  pilots  indicated  experiencing  vertigo  during 
some  of  the  flight  maneuvers  while  flying  the  symbology. 
None  of  the  pilots  experienced  any  form  of  disorientation 
that  affected  his  operation  of  the  aircraft  or  his  understanding 
of  the  relationship  of  his  aircraft  to  the  Command  Flight 
Path.  This  was  further  supported  by  the  majority  of  the 
evaluation  pilots'  statements  that  there  was  never  any  question 
as  to  where  they  were,  what  they  were  doing,  or  what  they 
should  be  doing  while  flying  the  CFPD  format. 

4.  The  concept  of  utilizing  the  VSI  and  the  HSI  with  the  CFPD 
format  provides  an  excellent  indication  of  the  wind  effect 
relative  to  take-off  and  climb,  cruise,  and  approach  and 
landing.  The  iaaediate  indication  of  a  change  in  wind  direction 
becomes  evident  when  corrections  in  heading  are  required 
to  stay  on  the  centerline  of  the  flight  path  on  the  VSI. 
The  drift  angle  also  becomes  apparent  with  just  a  glance 
at  the  aircraft  position  relative  to  the  flight  plan  on 
the  HSI.  When  the  drift  angle  is  minimal  a  head  wind  or 
tail  wind  can  be  determined  by  whether  or  not  the  velocity 
should  be  increased  or  decreased  in  order  to  maintain  position 
with  the  "how  goes  it"  circle.  This  is  not  the  ease  with 
the  symbology  because  displacement  of  the  discrete  symbols 
may  be  due  to  a  variety  of  causes  such  as  inability  to  maintain 
an  accurate  heading  or  attitude,  or  angle  of  attack  and 
airspeed  when  making  an  ILS  approach,  or  due  to  inherent 
lag  in  interpreting  the  information. 

In  addition  to  the  above,  turbulence  effects  were  no  different 
visually  in  the  CFPD  than  they  would  be  when  flying  VFR. 
It  is  believed  from  what  was  observed  during  the  flight 
test  and  the  analyses  of  the  performance  plots,  that  indication 
of  wind  shear  conditions  can  be  integrated  into  the  CFPD 
with  very  little  effort.  This  will  be  considered  during 
the  next  phase  of  the  program. 

c.  One  significant  weakness  in  the  CFPD  format  which  became  apparent 
during  the  flight  test  was  the  lack  of  realism  in  the  presentation 
of  the  velocity  control.  Careful  analysis  of  the  video  tapes 
and  the  ICS  comments  revealed  that  most  of  the  evaluation  pilots 
had  aome  trouble  maintaining  formation  position  on  the  lead 
aircraft  which  suggests  that  the  visual  cues  relative  to  the 
aircraft  were  inadequate.  Further  analysis  of  the  display  format 
itself  indicates  that  the  cues  presented  by  the  line  drawing 
of  the  lead  aircraft,  vithout  a  hidden  line  algorithm,  were 
not  realistic  enough  to  elicit  a  spontaneous  response  by  the 
pilot. 

Based  on  past  experience  with  many  simulated  images,  it  is  believed 
that  if  the  lead  aircraft  is  displayed  as  a  shaded  full  color 
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iaage  in  real  time,  Che  problem  of  the  pilot  maintaining  formation 
position  will  be  eliminated.  In  addition,  anticipatory  cues, 
such  as  torching  of  the  tail  pipe  when  power  is  required,  the 
deployment  of  speed  brakes  on  the  aircraft  image  as  a  deceleration 
comsiand,  or  the  dropping  of  gear  and  flaps  in  the  approach, 
will  greatly  enhance  the  pilot's  performance. 

Relative  to  the  dynamics  of  the  display,  a  variety  of  experi¬ 
ments  with  indicated  airspeed,  ground  speed,  and  their  deriva¬ 
tives,  were  conducted  during  actual  flight  tests.  Although 
further  investigation  of  these  paraneters  will  be  carried  out, 
it  is  fairly  evident  that  the  lead  aircraft  should  represent 
indicated  airspeed.  In  addition,  further  investigation  and 
experimentation  must  be  conducted  to  establish  the  most  effective 
format  for  the  lead  aircraft  in  order  for  the  pilot  to  maintain 
accurate  altitude. 


2.5.3  Conclusions  -  AIDS  HUD 

When  the  Hughes  AIDS  HUD  was  installed  in  place  of  the  VSI,  flights 
were  made  with  and  without  the  windscreen  translucent  curtain.  When  the 
outside  world  was  obscured,  there  appeared  to  be  little  difference  with 
either  display  format  on  the  HUD  or  the  VSI,  with  the  exception  that  some 
pilots  had  trouble  losing  the  display  on  the  HUD  because  of  the  critical 
eye  position  and  the  restricted  exit  pupil.  This  was  only  true  of  pilots 
having  limited  experience  flying  a  HUD. 

Another  exception  was  that  line  drawings  of  the  CFPD  on  the  HUD 
were  incomplete  with  corners  of  the  flight  path  trapesoids  not  being  closed, 
thus  producing  a  rather  poor  pictorial  image. 

In  order  to  evaluate  the  display  format  when  transitioning  from 
IFR  to  VFR  to  IFR,  it  was  intended  that  when  flying  the  HUD,  an  altitude 
would  be  selected  where  the  flight  plan  called  for  climbing  and  descending 
in  and  out  of  cloud  levels,  and  with  the  translucent  curtain  removed. 
This  phase  of  the  flight  test  plan  could  not  be  achieved  because  the  required 
weather  conditions  were  not  available  during  the  duration  of  the  flight 
test.  When  the  translucent  curtain  was  removed,  particularly  when  making 
HUD  approaches  to  Niagara,  the  pilots  did  indicate  that  the  display  was 
not  bright  enough  against  the  background  of  white  clouds  and  the  snow-covered 
ground. 


2.6  Recommendations 

In  view  of  the  significant  results  and  conclusions  achieved  during 
Phase  I  and  II  of  the  CFPD  program,  it  is  strongly  recommended  that  further 
exploratory  development  be  conducted  to  examine  the  feasibility  of  the 
CfPD  concept  for  tactical  operations,  and  for  the  development  of  a  shaded, 
full  color,  real  time  display  system  compatible  with  current  avionics  systems. 


Specifically,  a  program  it  recommended  consisting  of  the  following. 

Ti»K  \ 

Development  and/or  modification  of  existing  CFPD  algorithms 
to  generate  formats  in  real  time  and  color  for  all  modes  of  flight 
including: 

a.  VTOL,  VSTOL  and  CTOL  from  shipboard  and  land  bases. 

b.  Hovering/ loiter  flight. 

c.  Lateral  flight. 

d.  Reverse  flight. 

e.  Rotation. 

f.  Transitioning  flight  to  and  from  vertical/hovering. 

g.  Cruise. 

h.  Terrain  folloving/avoidance. 

TfllK,  l 

Preparation  of  specifications  that  will  be  used  to  define  the 
computer  graphics  display  system  hardware. 

Tig*  3 

Preparation  and  delivery  of  an  engineering  report  that  documents 
the  detailed  design  analysis  conducted  on  the  CFPD  system  to  be 
developed  to  sreet  the  airborne  operations  listed  in  Task  1. 

Ttffc  4 

Preparation  and  delivery  of  an  Integrated  Control  Document  which 
delineates  the  required  characteristics  for  aircraft/ system  integration 
based  on  the  Navy  aircraft  selected  for  the  flight  test. 

Tl»k„5 

Design,  development,  and  delivery,  concurrently  with  Task  4, 
of  the  software  programs  that  address  and  control  the  high  speed 
graphic  system  used  to  generate  the  display  formats. 

lilk-L 

Preparation  and  documentation  of  an  approved  set  of  system  check-out 
proceudres  to  be  used  during  the  conduct  of  bench  and  ground  system 
checks. 

Tlf  >  7 

Preparation  and  delivery  of  a  flight  test  plan  to  KADC  for  approval 
and  technical  support  during  the  test  program. 


Compilation  and  analysis  of  flight  test  data  and  the  preparation 
and  submittal  of  a  report  covering  the  overall  project  and  test 
results. 
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3.0  TECHNICAL  DISCUSSION 


The  Coonand  Flight  Path  Display  is  the  result  of  approximately 
35  years  of  various  Research  and  Development  programs  sponsored  by  the 
Navy  in  an  effort  to  establish  an  optimal  Man-Machine  Systems  interface. 

The  concept  of  a  completely  integrated  pictorial  display  for  aircraft 
vas  originally  conceived  in  1946  as  a  result  of  a  study  performed  by  the 
Flight  Section,  Special  Devices  Division,  Navy  Office  of  Research  and  Inven¬ 
tions,  in  conjunction  with  the  University  of  Illinois. 

It  should  be  emphasized  that  in  1946,  and  for  many  years  after, 
there  vas  no  known  means  for  displaying  the  concept. 

In  1952  the  Office  of  Naval  Research  vas  charged  by  the  Assistant 
Secretary  of  the  Navy  for  Air  to  establish  a  program  with  the  Bureau  of 
Aeronautics  to  develop  a  new  concept  for  aircraft  instrumentation.  This 
program  vas  originally  a  Navy  effort  conducted  jointly  by  the  Office  of 
Naval  Research,  Air  Branch,  the  Bureau  of  Aeronautics,  Instrument  Branch, 
and  the  Naval  Air  Development  Center.  Later,  the  Army  joined  the  program 
because  of  its  interest  in  improving  helicopter  instrumentation  at  which 
time  it  vas  named  the  Army  Navy  Instrumentation  Program  (ANIP). 

The  generalized  aircraft /Man-Machine  system  vas  identified.  Although 
ANIP  sponsored  work  in  each  of  the  system  areas,  those  of  the  central  computer 
and  displays  received  the  most  concentrated  research.  However,  the  technology 
vas  still  not  available  to  produce  the  required  display. 

Many  of  the  advanced  systems  now  installed  in  current  Navy  aircraft 
came  about  as  a  result  of  the  effort  of  this  program  which,  over  a  ten-year 
period,  produced  the  first  airborne  digital  central  computer,  improved 
cathode  ray  tubes,  and  initiated  the  practicability  of  microelectronics. 
All  of  these  advances,  when  properly  integrated  resulted  in  the  initial 
demonstration  of  the  concept  of  computer  graphics  generated  display  which 
was  produced  by  General  Electric  under  an  ANIP  contract. 

It  vas  not,  however,  until  1972-73  that  computer  graphics  reached 
a  point  where  real  time,  realistic  computer  generated  images  with  relatively 
small  computers  was  achieved.  This  break-through  in  technology  vas  presented 
for  the  first  time  to  the  Navy  at  the  First  Advanced  Aircrew  Display  Symposium 
held  at  the  Naval  Air  Test  Center  (KATC),  April  18-19,  1974. 

As  a  result  of  the  NATC  demonstration  and  interest  indicated  by 
DCNO  (AIR),  Naval  Air  Systems  Command  (NAVAIRSYSCOM)  through  the  Naval 
Air  Development  Center  (NADC)  sponsored  a  study  to  investigate  the  feasibil¬ 
ity  of  generating  a  pictorial  display  employing  real  time  computer  graphics 
techniques.  The  study  produced  a  demonstration  by  Northrop  Aircraft  Division 
in  a  flight  simulator  of  the  original  concept  of  pictorial  displays  developed 
under  the  ANIP  program. 

Previous  research'  and  development  efforts  had  clearly  established 
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visual  display  requirement  information  and  the  technical  means  for  generating 
the  displays.  The  only  remaining  unknovn  in  proving  the  concept,  currently 
referred  to  as  the  Command  Flight  Path  Display  (CFPD),  was  whether  or  not 
improved  flight  performance  could  be  achieved  during  actual  flight  under 
real  or  simulated  IFR  flight  conditions. 

In  an  effort  to  solve  the  remaining  unknown,  an  unsolicited  proposal 
dated  15  April  1981  was  submitted  to  the  Naval  Air  Development  Center  by 
the  Resource  Management  Systems  (RMS)  Division  of  Systems  Associates,  Inc. 
of  California  (SAI)  for  the  development  of  a  CFPD  System.  The  proposal 
consisted  of  the  following  phases: 

Phase  0  -  Program  Definition,  Organization  and  Support 
Identification  for  Flight  Testing  the  Command 
Flight  Path  Display. 

Phase  I  -  Development  of  the  CFPD  Flight  Test  System. 

Phase  II  -  Flight  Test  of  the  Command  Flight  Test  System. 

Phase  III  -  Flight  Test  of  the  Command  Flight  Path  Display 

in  a  current  Navy  Operational  Aircraft. 

In  response  to  this  proposal,  a  contract  was  awarded  to  SAI/RMS 
on  20  August  1981  by  NADC,  sponsored  by  NAVAIR-03 ,  authorizing  the  execution 
of  Phase  0. 

On  20  April  1982,  NAVAIRSYSCOM  authorized  SAI/RMS  to  proceed  with 
PHASE  1  of  the  CFPD  program. 

On  5  May  1982  the  kick-off  meeting  for  PHASE  I  was  held  at  ARVIN/CALSPAN 
in  Buffalo,  New  York. 

The  System  requirements  in  general  are  as  follows: 

-  Computer  Graphics  Picture  Processor 

-  Display  Media  (CRTs) 

HOD 

VSI 

HSI 

-  Host  Computer 

-  Peripheral  Components  (Writers,  Recorders,  etc.) 

-  Converters  (A-D,  etc.) 

-  Sensors 

-  Interconnections/ Interfaces 


3.1  System  Design 

The  system  design  is  shown  in  the  CFPD  system  diagram  (Figure  3-1). 
Few  changes  were  made  from  the  initial  system  diagram.  In  most  cases, 
those  changes  made,  were  the  result  of  delivery  times  being  incompatible 
with  the  project  schedule. 
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Only  two  pieces  of  equipment  were  militari zed— the  inertial  navigation 
system  and  the  Hughes  AIDS  HUD.  The  remaining  components  were  commercial 
units.  The  commercial  equipment  was  hardened  and  then  vibration  tested 
by  Calspan  prior  to  installation  in  the  aircraft.  The  system  was  operational 
for  over  ninety  hours  of  simulation  and  over  twenty-three  hours  of  flight 
time.  The  only  component  to  malfunction  from  the  start  of  the  ground  simula¬ 
tion  to  completion  of  the  flight  test  was  the  HUD.  In  February  the  HUD 
overheated  during  ground  simulation  and  a  failed  IC  chip  was  replaced. 
On  March  8th  a  high  voltage  problem  prevented  use  of  the  HUD  on  the  sixth 
CFPD  flight. 


3.1.1  Computer  Graphics  Picture  Processor 

The  concept  of  a  completely  integrated  pictorial  display  for  aircraft 
required  a  powerful  picture  processor  in  order  to  generate  realistic  images 
in  real  time.  The  key  to  developing  the  CFPD  system  was  the  acquisition 
of  the  Evans  and  Sutherland  PS-300.  The  PS-300  is  a  high  performance, 
stroke  writing  system,  capable  of  real  time  interaction  computer  graphics. 
It  can  accomplish  its  high  speed  by  handling  the  graphics  operations  internally 
while  the  host  computer  runs  the  application  program  relatively  uninterrupted. 
Short,  dense  bursts  of  information  are  passed  through  a  low-bandwidth  interface. 

The  specific  requirements  of  the  Command  Flight  Path  Display  Program 
necessitated  the  development  of  customized  firmware  by  Evans  and  Sutherland. 
The  CFPD  and  the  Symbology  displays  required  a  much  higher  rate  of  input 
command  processing  than  was  possible  with  the  standard  unit.  The  modification 
allowed  for  binary  data  transmissions  over  the  standard  56K  baud  interface. 

The  PS- 300  was  a  commercial  unit  and  required  some  modifications 
to  ensure  its  reliability  in  an  aircraft  environment.  Plans  to  install 
cards  with  standard  card  edge  connectors  after  delivery  of  the  unit,  were 
changed  when,  after  protracted  negotiations,  Evans  and  Sutherland  was  able 
to  deliver  a  unit  with  that  type  card  already  installed.  The  floppy  disc 
and  power  switch  were  relocated  to  allow  access  on  the  same  side  as  the 
circuit  cards  when  installed  in  the  aircraft.  In  addition  the  cabinet 
was  hardened  to  prevent  as  much  movement  as  possible,  as  well  as  being 
shock  mounted  on  a  metal  platform  to  the  aircraft  floor. 

Manufacturer's  warranties  on  the  PS- 300  were  honored  until  modifications 
were  made.  Service  agreements  were  arranged  in  the  event  engineering  or 
repair  work  was  required  during  the  critical  flight  test  period. 

No  provisions  for  alternate  power  sources  were  available.  Major 
modifications  to  the  PS-300  circuitry  and  external  clock  control  would 
have  been  required.  As  a  precaution  a  restart  capability  was  included 
in  the  flight  plan  software  to  enable  initialization  at  any  location  should 
power  be  lost  to  the  PS-300  resulting  in  a  program  crash. 


3.1.2  Display  Media 


The  PS-300  can  be  equipped  with  as  many  as  four  displays.  The  standard 
19"  (48  cm)  monochrome  display  was  used  during  software  development  at 
Intermetrics  Inc.  Space  constraints  in  the  aircraft  evaluation  cockpit 
required  utilization  of  much  smaller  displays  to  accomplish  the  flight 
test. 


Three  displays  were  required  for  information  display  in  the  aircraft 
at  any  one  time.  Information  relative  to  the  real  world  vertical  plane 
presented  on  a  cathode  ray  tube  (CRT)  called  the  Vertical  Situation  Indicator 
or  VSI;  and  relative  to  the  real  world  horizontal  plane,  on  a  cathode  ray 
tube  called  the  Horizontal  Situation  Indicator  or  HSI.  Both  the  VSI  and 
HSI  were  located  in  the  cockpit.  The  third  display  was  located  in  the 

aircraft  cabin.  It  was  a  repeater  of  the  VSI  and  served  as  a  source  for 
video  taping  of  the  display. 

Three  nine-inch  CRTs  with  drivers  were  purchased  from  Xytron,  Inc. 
of  Sylmar,  California.  The  three  custom  displays  were  compatible  with 
the  PS-300,  and  rugged  enough  to  withstand  the  aircraft  environment. 

The  Advanced  Integrated  Display  Systems  (AIDS)/F-18  Diffractive  Head-Up 

Display  (HUD),  developed  by  Hughes  for  the  Naval  Air  Development  Center, 

was  also  made  available  for  the  CFPD  program.  It  replaced  the  Xytron  panel 
mounted  VSI  when  used.  Integration  of  the  AIDS  HUD  required  a  writing 
speed  reduction  of  50Z  in  the  PS-300  and  doubled  the  brightness  of  the 
Xytron  displays.  The  HUD  line  straightness  and  line  segment  closures  were 
optimized  for  use  with  the  McDonnell  Aircraft  Company  F-18  ground  simulator. 
This  was  done  because  the  HUD  was  shared  during  the  flight  test  with  the 
ground  simulator.  Readjustment  of  the  HUD  would  have  meant  replacement 
of  capacitors  each  time  the  HUD  was  relocated. 

Translucent  material  was  used  to  completely  cover  the  test  cockpit 
windows  to  simulate  zero-zero  conditions  while  using  the  Xytron  VSI  and 
to  screen  the  area  outside  the  HUD  field-of-view  when  not  in  actual  minimal 
weather  conditions. 


3.1.3  Host  Computer 

Original  intentions  centered  on  the  procurement  of  a  militarized 
airborne  computer.  The  Norden  PDP  11/34  and  11/70  were  leading  candidates. 
The  11/70  could  not  be  delivered  in  time  to  meet  program  schedules  however. 
The  capability  of  the  11/34  to  meet  program  requirements  was  in  doubt  plus 
the  cost  of  the  unit  was  prohibitive. 

Research  into  the  use  of  commercial  units  indicated  successful 
operation  in  an  aircraft  environment.  The  commercial  PDP  series  was  considered 
and  the  11/44  was  determined  to  be  the  smallest  unit  available  to  meet 
requirements.  Delivery  times  were  compatible  with  program  schedules  and 
the  cost  was  well  below  the  militarized  version. 

The  PDP  11/44  was  selected  and  configured  with  236  KB  memory,  dual 


l] 


TU  58  tape  cartridges  for  ground  check-out,  RSX-11S  4.0  operating  system, 
H9642  cabinet,  and  a  battery  backup  that  provided  a  minimum  data  retention 
time  of  twenty  minutes  in  the  event  of  power  loss.  A  floating  point  processor 
(FP11-F)  for  the  PDP  11/44  provided  up  to  seventeen  digits  of  precision 
as  well  as  integer  to  floating  point  conversions.  A  DMR  11-AE  network 
link  and  RS  449  cable  provided  the  interface  to  the  PS-300  along  with  the 
high-speed  DEC  interface  upgrade  option  and  the  cross-interface  compatibility 
software. 


3.1.4  Peripheral  Components 

Peripheral  components  were  used  for  interfacing  with  the  host  computer 
and  for  recording  data  deemed  necessary  for  pilot  performance  comparison. 

3. 1.4.1  DEC  Writer  LA-12D 

A  Correspondent  portable  printing  terminal,  DEC  writer  LA-12D,  with 
cable  BC03M-15  was  provided.  The  interactive  terminal  was  mounted  at  the 
CFPD  engineer's  station  in  the  cabin  of  the  aircraft  and  supported  the 
display  and  modification  of  program  data  during  preflight  loading,  and 
in  most  cases,  during  actual  flight. 

Parameter  modifications  such  as  path  segment  dimensions  and  spacing, 
velocity  indicator  placement  and  size  and  symbol  sensitivities  could  be 
changed  easily  with  the  LA-12D.  It  was  also  used  to  print  out  selected 
"quick  look"  parametric  data  while  on  the  Command  Flight  Path  Display. 


3.x. 4. 2  TIFS  58  -  Channel  Recorder 

The  TIFS  58  -  channel  recorder  was  part  of  the  aircraft  and  not 
required  for  the  CFPD  System.  It  was  shown  as  part  of  the  system  because 
it'  was  utilized  for  its  "quick  look"  capability.  ‘Flight  data  of  interest 
could  be  recorded  and  looked  at  after  each  flight  if  required. 


3. 1.4. 3  Magnetic  Tape  System  TS-131  PE 

A  commercial  TS-131  PE  Magnetic  Tape  System  was  utilized  to  record 
data  during  the  flight  test.  The  procedure  for  validating  the  Command 
Flight  Path  Display  concept  consisted  of  comparing  the  flight  performance 
of  a  number  of  pilots  while  flying  a  specific  flight  plan,  first  utilizing 
a  slightly  modified  standard  symbology,  followed  by  flying  the  same  flight 
plan  with  the  Command  Flight  Path  Display. 

The  system  consisted  of  a  TC-131  PE  magnetic  tape  controller  and 
a  Kennedy  9800  tape  drive.  The  tape  controller  was  imbedded  in  the  PDP 
11/44  computer.  The  tape  drive  was  a  ruggedized,  dual  density,  37.5  inch 
per  second,  9  track  configuration  with  a  1200  foot  reel  capacity,  cabling, 
and  diagnostics.  The  system  was  selected  for  its  combination  of  size, 


weight,  power  requirements,  dependability,  and  delivery  schedule.  Selected 
data  was  recorded  without  conditioning  at  a  3  HZ  sampling  rate. 


The  magnetic  Cape  system  also  functioned  as  the  loading  mechanism 
for  the  bootable  Command  Flight  Path  Display  software. 


3. 1.4. 4  Video  Recording  System 

A  video  recording  of  all  test  flights  was  made.  The  video  portion 
shoved  the  vertical  situation  display  as  seen  by  the  pilot  in  the  evaluation 
cockpit.  The  audio  portion  included  ICS  and  radio  communication. 

The  recording  was  accomplished  by  mounting  a  repeater  VS1  in  the 
aircraft  cabin.  A  Coho  model  2810-200  video  camera  was  mounted  facing 
the  repeater  VSI  along  with  a  Sony  VO  4800  recorder.  A  Sony  CVM-115  video 
monitor  was  also  mounted  on  the  console  in  front  of  the  engineer  work  station 
to  provide  in-flight  check  of  recorded  picture  quality  and  ground  playback 
capability. 


3. 1.4. 5  Workload  Assessment  Device 

Software  provisions  were  made  for  the  incorporation  of  a  Workload 
Assessment  Device  (WAD).  The  device  was  used  to  measure  pilot  workload. 
The  hardware  was  not  installed  after  the  flight  time  for  proving  the  Command 
Flight  Path  Display  concept  was  reduced  to  twenty  hours. 


3.1.5  Converters 

Sensor  information  is  channeled  to  the  lab  peripheral  accelerator 
and  Input/Output  interface  chassis  for  conversion.  The  smoothed  sensor 
input  data  are  then  sent  to  the  PDP-11/ 44. 


3. 1.5.1  Lab  Peripheral  Accelerator 

The  peripheral  accelerator  is  an  intelligent  high  speed,  direct 
memory  access  microprocessor  subsystem  for  realtime  I/O  devices.  It  is 
designed  to  increase  realtime  I/O  throughput  by  reducing  the  high  interrupt 
load  on  the  CPU. 


3. 1.5. 2  Input/Output  Interface  Chassis 

The  input/output  chassis  was  a  standard  DEC  expansion  chassis  equipped 
with  a  LPA11-K  direct  memory  access  subsystem  and  an  array  of  purchased 
and  Calspan-buil t  circuit  cards.  The  chassis  electronic  circuits  were 
designed  specifically  to  process  the  sensor  data  which  was  a  composite 
of  analog,  discrete,  and  serial  bit  stream  information. 


The  sixty-four  analog  input  channels  were  wired  to  the  TIFS  Model 
Computer  Patch  Panel  for  sensor  data  input.  Forty  of  the  sixty-four  single- 
wire  analog  inputs  were  filtered  in  a  Calspan  aliasing  filter  card.  DEC 
multiplexer  and  twelve  bit  A/D  converter  cards  were  used  to  process  the 
analog  data. 

The  serial  bit  stream  data  from  the  INS  was  converted  to  labeled 
thirty-two  bit  parallel  format  in  a  Cal  span-designed  and  fabricated  circuit 
card. 

Synchro  outputs  from  the  INS  were  converted  to  parallel  digital 
data  in  a  Calspan  circuit  card  using  two  Data  Device  Corp.  four  channel 
multiplexer  modules  and  a  synchro-to-digital  converter.  INS  and  other 
aircraft  sensor  discrete  inputs  were  level  shifted  and  buffered  in  a  Cal  span- 
fabricated  card.  All  digital  data  were  controlled  by  a  DEC  LPA11-K  Direct 
Memory  Access  system  configured  to  conserve  PDP-11/44  computer  cycle  time. 

Provisions  were  made  to  couple  a  Workload  Assessment  Device  (WAD) 
to  the  I/O  chassis  but  the  WAD  was  not  used  during  the  program.  Four  channels 
of  D/A  from  the  I/O  chassis  to  the  analog  patch  panels  were  also  available 
for  monitoring  or  recording. 


3.1.6  Sensors 

An  inertial  navigation  system  was  required  for  position  and  inertial 
velocity  input.  Relatively  high  update  rates  as  well  as  resolution  require¬ 
ments  dictated  a  non  standard  system.  A  Litton  Aero  Products  LTN-72  unit 
with  72-9-07  series  programming,  prewired  pallet,  battery,  and  cables  was 
obtained.  The  unit  provided  ♦/-  twenty  foot,  resolution  on  latitude  and 
longitude  and  updated  the  inertial  velocities  at  24  HZ. 

On  board  sensor  inputs  from  the  TIFS  aircraft  included  ILS  signal 
during  approach,  radar  altimeter  reading,  TIFS  inertial  data  of  yaw,  pitch, 
and  roll,  airspeed,  altimeter,  angle  of  attack,  rate  of  climb,  and  heading. 

3.1.7  Interconnections/Interfaces 

3. 1.7.1  Host  Computer/Graphics  Picture  Processor  Interface 

The  link  between  the  PDP-11/44  computer  and  the  PS- 300  graphics 
picture  processor  was  a  DMR11-AF.  high  speed,  synchronous,  serial  data  link. 
The  link  consisted  of  two  circuit  cards  which  resided  on  the  Unibus  in 
the  PDP-11/44  (each  card  was  the  full  six  connectors  in  length),  and  adaptor 
card  mounted  external  to  the  PDP-11/44  but  connected  to  the  cards  with 
ribbon  cable,  an  RS-449  extension  cable,  an  E&S  RS-449  SYNC  six-foot  cable 
assembly,  a  RS-449  loop  back  plug  and  a  DEC/PMR11  software  package. 

3. 1.7. 2  Display  Interface 

The  Xytron  interface  was  standard  for  the  PS-300.  Ninety-foot  cables  were 


installed  to  connect  the  cockpit -mounted  displays  to  the  picture  processor. 
The  two  cables  to  the  forward  Xytron  displays  and  the  25  foot  cable  to 
the  cabin  display  from  the  picture  processor  used  the  E&S  recommended  Belden 
9221  miniature  coax  cable.  A  thirty-foot  coax  cable  connected  the  picture 
processor  to  the  display  repeater. 

The  HUD  required  interface  circuits  to  be  compatible  with  the  PS-300  outputs. 
A  chassis  was  fabricated  at  Calspan  to  enclose  the  interface  hardware  and 
was  mounted  in  close  proximity  to  the  HUD. 

The  chassis  contained: 

1.  Attenuators  to  adjust  the  X  and  Y  signal  scale  factors. 

2.  An  analog  delay  line  for  the  Z  signal  with  a  range  of 
250  nanoseconds  in  ten  steps. 

3.  Input  and  output  isolation  amplifiers  for  the  delay 
line. 

4.  Relay  control  for  HUD  forced  air  cooling  blower. 

5.  +/ -  fifteen  volt  regulators  for  delay  lin*e. 

6.  Attenuator  circuit  with  potentiometer  for  Z  axis  amplitude 
matching. 

The  PS-300  with  +/“  5V  of  output  range  was  able  to  drive  the  RUD 

the  maximum  twenty  degrees  of  vertical  deflection  (+/-  10  degrees)  and 

twenty  degrees  (+/-  10  degrees)  deflection  in  the  X  axis.  The  HUD  was 
capable  of  thirty  degree  field  of  view  (♦/-  15  degrees)  in  the  X  direction. 

The  attenuators  on  the  X  and  Y  channels  were  for  fine  adjustment 
of  the  display  size.  The  voltage  divider  in  the  Z  axis  reduced  the  4V 
max  drive  signal  to  IV  max  for  the  HUD.  The  relay  allowed  operation  of 
the  115V  400  Hz  HUD  blower  via  a  28V  control  line  from  the  HUD. 

The  delay  line  in  the  Z  axis  was  required  for  time  synchronizing 
the  Z  axis  with  the  X  and  Y  drive  signals.  X  and  Y  deflection  signals 
typically  lagged  the  Z  signals  due  to  inductance  of  the  yoke  windings. 
The  display  generator  had  an  unused  zero  to  500  nanosecond  delay  line  in 
the  Z  axis  but  E&S  current  design  practice  was  to  use  a  zero  to  250  nanosecond 

delay  circuit  installed  in  each  display  instead.  Since  the  AIDS  HUD  was 

a  prototype  unit  not  equipped  with  a  Z  axis  delay,  Xytron  Inc.  provided 
a  delay  line  assembly  identical  to  their  display  delays.  With  the  delay, 
the  beam  started  writing  line  segments  before  the  beam  was  stabilized  at 
the  start  point  and  cut  off  the  beam  before  the  segment  end  point  was  reached. 

The  HUD  signal  cable  from  the  PS-300  PORT  0  was  made  from  two-wire 
shielded  cable  for  maximum  noise  cancelling  in  the  HUD.  Although  the  HUD 
was  capable  of  writing  stroke  over  a  raster  scan  it  was  used  only  in  the 
stroke  mode  (calligraphic)  for  the  CFPD  program. 

Before  arrival  at  Calspan,  the  RUD  input  circuits  were  altered  for 
compatibility  with  the  current  McDonnell  Aircraft  Company  F-18  HUD  installa¬ 
tion.  Modifications  which  affected  the  CFPD  installation  were: 


a.  Channel  "B"  inputs  were  used. 

b.  True  differential  inputs  on  UNELANK  were  disabled.  Only  UNBLANK 
Hi  was  required. 


3.2  Acquisition  of  Equipment 

After  several  iterations  of  the  matrix  responsibilities,  the  Naval 
Air  Development  Center  assumed  responsibility  for  furnishing  all  hardware 
with  the  exception  of  minor  interface  components.  A  considerable  delay 
in  the  release  of  the  first  two  purchase  orders  to  DEC  and  Evans  and  Sutherland 
resulted  in  a  reevaluation  of  the  situation.  Similar  delays  on  the  remaining 
orders  could  not  be  tolerated  if  the  program  schedule  was  to  be  maintained. 
Approval  was  given  to  Calspan  for  the  purchase  of  the  magnetic  tape  system, 
the  head  down  display,  the  second  PS-300,  the  interface  electronics  chassis, 
and  the  second  high  speed  interface. 

The  following  hardware  and  software  items  were  furnished  for  the 
CFPD  program. 


HARDWARE; SOFTWARE  LIST 


I teg  21X  Model  Description 

DIGITAL  EQUIPMENT  CORPORATION 


Ordered  Delivery 

Bv  Jttf 

tz 


1 

1 

11X44-CA 

PDP-11 /44W256KB  with  TU58 
Tape  Cartridge  and  K9642 
Cabinet 

NADC 

5 

Oct 

82 

2 

1 

LPA-11KK 

Lab  Peripheral  Accelerator 
with  A-D  Converter 

Calspan 

23 

Jul 

82 

3 

1 

BC11A-15 

Backplane  Cable 

Calspan 

23 

Jul 

82 

4 

1 

FP11-F 

Floating  Point  Accelerator 

NADC 

5 

Oct 

82 

5 

1 

DD11-DK 

Expansion  Backplane 

NADC 

5 

Oct 

82 

6 

1 

KW11-K 

Progressive  Real  Time  Clock 

NADC 

5 

Oct 

82 

7 

2 

DMR-ll-AE 

Network  Link,  RS422 

NADC/ 

5 

Oct 

82/ 

Calspan 

16 

Nov 

82 

8 

1 

H7750-AA 

Battery  Backup 

NADC 

5 

Oct 

82 

9 

1 

LA-12D 

Decwriter 

SAI/RMS 

4 

Nov 

82 

10 

1 

BC03M-25 

Null  Modem  Cable 

SAI/RHS 

4 

Nov 

82 

35 


$ 


% 


11 

1 

QJ642-AK 

RSX-11S  Operating  System 

NADC 

5 

Oct 

82 

12 

3 

DR11-K 

Digital  Interface  Package 

Cal  span 

23 

Jul 

82 

13 

1 

AM11-K 

Multiplexer 

Cal  span 

23 

Jul 

82 

14 

1 

BAU-KE 

Expander  Box 

Cal  span 

23 

Jul 

82 

15 

1 

DD11-DK9 

Expansion  backplane 

Cal  span 

23 

Jul 

82 

16 

i 

DD11-CK4 

Expansion  backplane 

Cal  span 

23 

Jul 

82 

17 

2 

High  Speed  Interface  Up¬ 

NADC/ 

10 

Nov 

82/ 

grade  Option 

Cal span 

1 

Dec 

82 

18 

Converters,  Tools,  etc. 

Calspan 

19 

1 

RSX-llS  Operating  System 

INC  1 

i  CTJ’ 

rHFRT  ANTi 

Upgrade  to  Version  4.0 

Calspan 

5  Aug 

82 

1 

i-  aV. 

1 

L  n  LIU4U1  u 

PS-300 

Std  Config  v/  RS/232  Inter- 

NADC 

10 

Nov 

82 

2  1  PS-300 


face  v/o  Cable  &  Connectors 

-  Graphics  Control  Processor 

-  1MByte  Memory 

-  Display  Processor 

-  19"  Monochrome  Display 

-  Install  &  60  Day  Maintenance 

-  User  &  Oper.  Documentation 

Mod  Config  v/RS232  Interface  Cal  span 

-  Graphics  Control  Processor 

-  IMByte  Memory 

-  Display  Processor 


1  Dec  82 


3 

1 

Alphanumeric  Keyboard/ 12 
Functions  Keyboard 

NADC 

10  Nov  82 

4 

1 

LED  Option  for  Keyboard 

NADC 

10  Nov  82 

5 

2 

56KB  Interface  Upgrade 
Option  (DEC) 

NADC/ 

Calspan 

10  Nov  82 

6 

1 

Custom  Firmware  Functions 

RMS 

22  Oct/ 

8  Nov  82 


7  5 


Programmer  Training  Course  R11S 


21  Jun/ 

2  Aug  82 


1 

1 

TS-131PE 

Magtape  System 

Cal  span 

5  Sep  82 

XYTRON 

1 

3 

X-1813 

9"  CRTs 

Cal  span 

7  Dec  82 

2 

3 

AB9R-7B 

Drivers  &  Cables 

Cal span 

7  Dec  82 

OTHER 

1 

1 

LTN-72 

Inertial  Navigation  Plat¬ 
form 

NADC 

3  Oct  82 

2 

1 

Coho 

2810-200 

Video  Camera 

NADC 

28  Oct  82 

3  * 

1 

Sony  AC 
VO-3800 

Video  Recorder 

NADC 

15  Dec  82 

4 

1 

Sony  CVM 
-115 

Video  Monitor 

NADC 

28  Oct  82 

5 

30 

Magnetic  Tapes 

NADC 

Nov  82 

6 

30 

Video  Tapes 

NADC 

Dec  82 

7 

1 

Hughes 

"AIDS"  HOD 

NADC 

18  Nov  82 

8 

1 

RS  449 

Cable 

Cal span 

Nov  82 

9 

4 

Cables  (PS-300  to  Drivers) 

Cal span 

1  Dec  82 

10 

2 

UNITS ON 
PS-62-66D 

60  HZ  Frequency  Converters 
v/  Monitors  &  Relays 

Cal span 

Aug  82/ 
Sep  82 

Delays  vere  experienced  when  installation  was  required  by  the  manufac¬ 
turers'  field  representatives.  In  this  case  installation  refers  to  unpacking, 
setting  up,  and  diagnostic  check-out.  Scheduling  for  installation  had 
to  be  arranged  after  delivery  and  was  dependent  on  the  field  representative's 
priorities.  In  the  case  of  the  PDP  11/44  and  the  first  PS- 300,  installation 
did  not  take  place  until  ten  and  thirteen  days  after  delivery  respectively. 

Warranties  on  the  hardware  vere  honored  until  modifications  vere 
made  or  the  equipment  was  installed  in  the  aircraft.  Arrangements  vere 
made  by  NADC  for  priority  service  during  the  test  flight  timeframe  in  the 
event  of  a  hardvare  failure. 


3.2.1  Ruggedization  of  Equipment 

The  CFPD  system  was  comprised  mainly  of  standard  commercial  equipment. 
To  ensure  proper  operation  in  the  aircraft  environment  and  to  satisfy  Air 
Force  safety  concerns  the  equipment  was  ruggedized  by  Arvin/Calspan.  The 
two  exceptions  to  the  ruggedization  were  the  inertial  navigation  system 
and  the  HUD,  which  were  militarized  units.  Upon  completion  of  the  ruggedi¬ 
zation  the  equipment  was  submitted  to  vibration  testing  under  power.  All 
equipment  was  successfully  tested  and  certified  safe  for  flight  in  the 
CFPD  Class  II  Modification,  Part  II. 

3. 2. 1.1  Ruggedization  of  the  PDP-11/44  and  I/O  Chassis 

The  following  steps  were  performed  on  both  units. 

a.  The  chassis  were  disassembled,  including  the  internal  power 
modules,  and  inspected  for  flightworthy  hardware  and  wiring. 
Locking  hardware  including  lockwashers,  fibernuts,  locktite 
and  glyptol  were  added  as  required. 

b.  Hiring  was  inspected  for  security  and  support— especially  near 
terminations.  Support  was  provided  as  required. 

c.  Ribbon  cables  were  routed  to  prevent  chafing. 

d.  Clips  were  added  across  the  tops  of  the  DEC  circuit  cards  to 
minimize  flexure  of  the  boards.  Three-eighths  inch  thick  closed¬ 
cell  foam  material  was  added  between  the  outside  boards  and 
the  chassis  sides  to  rigidize  the  groups  of  circuit  boards. 

e.  Strain  relief  clamps  were  used  where  cabling  entered  the  chassis 
to  prevent  unnecessary  tension  on  the  internal  terminations 
during  flight  or  handling  the  chassis. 

f.  Each  circuit  card  was  inspected  for  components  which  could  have 
leads  broken,  could  become  disconnected  or,  in  the  case  of  DIP 
switches,  change  state  under  vibration.  A  silastic  type  compound 
was  used  as  required. 

g.  Foam  rubber  pads  were  installed  in  the  upper  cover  to  depress 

the  circuit  cards  and  prevent  them  from  disconnecting  from  the 
backplane  connectors.  These  same  pads  provided  damping  for 

circuit  card  lateral  motion. 


3. 2. 1.2  Ruggedization  of  the  Computer  Graphics  Picture  Processor 

The  Computer  Graphics  Picture  Processor  was  electrically  equivalent 
to  a  standard  Evans  and  Sutherland  PS-300.  The  following  physical  changes 
were  made  for  this  flight  program. 

a.  Main  system  circuit  cards  were  braced  with  strips  of  one-half 
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inch  closed-cell  foam  sheet  to  prevent  circuit  board  flexure 
while  minimizing  disruption  of  cooling  airflow. 

b.  Cabling  from  the  backplane  to  the  standard  video  output  ports 
was  stowed  and  new  cabling  and  output  connectors  (CANNON  Royal 
D  type)  were  installed. 

c.  Circuit  cards  were  inspected  for  items  susceptible  to  breakage 
of  component  leads  or  disconnection  under  vibration.  Silastic 
compound  was  applied  as  required. 

d.  Floppy  disc  drive  and  main  system  power  switches  were  relocated 
for  improved  access  after  installation  in  the  aircraft. 

e.  Front  and  rear  cabinet  panels  were  removed. 

f.  The  cabinet  top  was  replaced  with  a  reinforced  plexiglass  plate. 

g.  Internal  wiring  and  hardware  were  secured. 

h.  The  unit  was  mounted  to  a  support  plate  and  Aeroflex  Labs  Inc. 
shock/vibration  isolators  chosen  for  shock  load  and  the  expected 
vibration  environment. 

3. 2. 1.3  Ruggedization  of  Displays  and  Display  Drivers 

The  Xytron  display  chassis  and  the  display  driver  chassis  were  modified 
as  follows. 

a.  All  hardware  was  checked  for  tightness  and  locking  devices. 
Lockwashers,  self  locking  nuts,  glyptol  and  locktite  were  used 
where  appropriate. 

b.  Hire  mounting  was  modified  where  necessary  to  prevent  chafing 
or  binding  and  cables  secured  to  minimize  movement  during  flight. 

c.  Circuit  cards  were  visually  inspected  for  components  susceptible 
to  lead  failure  or  disconnection  under  vibration.  They  were 
secured  with  silastic  compound. 

d.  Circuit  cards  and  heavy  components  were  secured  to  prevent  movement 
under  vibration. 


3. 2. 1.4  Ruggedization  of  the  Magnetic  Tape  System 

Ruggedization  of  the  magnetic  tape  system  was  accomplished  in  three 
areas— the  internal  part  of  the  transport,  the  interconnect  cabling  and 
the  tape  controller  card.  Internal  to  the  transport,  all  hardware  was 
checked  for  tightness,  and  lockwashers  and  locktite  or  glyptol  was  added 
where  appropriate.  All  internal  wiring  was  secured  to  prevent  flexing— 


especially  near  termination.  The  tape  recorder  was  operated  in  the  run 
and  rewind  mode  while  undergoing  vibration  testing  to  insure  faultless 
operation  in  the  aircraft  environment. 

Three  ribbon  cables  provided  the  connections  from  the  tape  transport 
to  the  tape  controller  card.  At  the  transport  end,  the  cables  attached 
to  interface  adapter  cards  that  mated  with  a  printed  circuit  card  edge 
in  the  transport.  Foam  blocks  were  secured  to  the  transport  and  the  ribbon 
cables  and  adapter  cards  were  attached  to  the  blocks  for  support.  The 
ribbon  cables  were  secured  with  lacing  cord  and  Adel  straps  to  cabinet 
tie  points. 

The  tape  controller  card  was  treated  as  part  of  the  PDP-11/44  ruggedi- 
zation.  Special  care  was  taken  to  support  the  tape  controller  card  to 
prevent  flexing  of  the  board.  Half  inch  thick  strips  of  resilent  closed-cell 
foam  material  were  installed  between  the  tape  controller  card  and  adjacent 
cards  with  care  taken  to  minimize  blockage  of  cooling  air.  The  cables 
from  the  transport  were  connected  directly  to  the  controller  card  so  strain 
relief  was  provided  where  the  cables  entered  the  computer.  Protection 
against  chafing  or  pinching  the  cables  in  the  computer  was  also  added. 


3.3  Software  Development 

The  CFPD  software  design  and  development  effort  was  performed  by 
three  corporations— Intermetrics  Inc.,  Arvin/Calspan  Inc.,  and  Evans  & 
Sutherland  Corp.  Their  contributions  to  the  effort  are  described  in  the 
following  sections.  Additional  information  on  the  software  interface  can 
be  found  in  Intermetrics  Report  Ho.  IR-KA-244. 


3.3.1  Intermetrics1  Contribution 

Intermetrics  Inc.  maintained  overall  responsibility  for  the  software 
system  design.  In  addition,  Intermetrics  designed  and  developed  the  Command 
Flight  Path  Display  specific  application  software,  generated  the  RSX-11S 
operating  system,  and  integrated  the  Calspan  and  Intermetrics  software 
into  a  "bootable"  load  tape  for  the  runtime  system. 

The  development  approach  adopted  for  this  effort  is  described  in 
Section  3. 3. 1.1.  A  high  level  description  of  the  software  developed  is 
provided  in  Section  3. 3. 1.2. 


3. 3. 1.1  Development  Approach 

The  manner  in  which  the  CFPD  project  was  approached  consists  of 
two  parts:  an  overall  philosophy  of  software  development  and  the  methodology 
of  software  development. 


3. 3. 1.1.1  Philosophy 


The  manner  in  which  a  project  is  approached  is  normally  determined 
by  requirements.  CFPD  had  three  sets  of  "requirements”:  those  outlined 

and  defined  by  the  contract,  those  derived  from  the  nature  of  the  project 
and  those  established  by  Intermetrics.  Each  of  these,  to  a  greater  or 
lesser  degree,  directed  the  software  development  activities  throughout 
the  project  and  served  to  focus,  and  at  times,  refocus  the  developers' 

thought  processes. 

Contractually,  the  system  was  required  to  be  functionally  correct 
according  to  the  project  specifications.  The  CFPD  display  software  was 
to  accept  sensor  data  as  input,  compute  the  necessary  flight  parameters 
and  present  graphical  displays  as  output.  The  software  needed  to  be  reliable, 
in  other  words,  barring  any  hardware  problems  the  system  remained  functional 
and  uncorrupted.  Also  in  the  event  of  a  detected  problem,  recovery  was 

necessary,  at  least  to  the  extent  of  system  re-initialization.  The  specifica¬ 
tions  included  the  aspect  of  "real-time"  processing  and  synchronization 

of  multi-tasks  and  multi-processors;  it  also  established  the  low  priority 
of  such  areas  as  fault-tolerance,  maintainability  and  documentation. 

There  were  also  constraints  and  requirements  derived  from  the  unique 
specifics  of  the  project  as  a  research  and  development  effort.  It  was 
recognized  that  there  were  areas  in  which  answers  to  coding  or  implemen¬ 
tation  questions  did  not  exist  but  these  areas  would  be  investigated  as 
part  of  the  project  itself.  The  project,  therefore,  was  approached  as 
a  one-pass  task.  The  software  was  required  to  function  as  specified  yet 
could  be  written  as  "throw-away"  code;  the  best  algorithms  and  fastest 
code  were  sacrificed  for  good,  working  algorithms  and  reasonably  fast  code. 
The  idea  was  that  this  fact-finding  project  would  answer  some  questions 
but  it  was  not  expected  to  produce  a  fully  operational  product  at  this 
time;  in  terms  of  phases,  this  was  seen  as  the  initial  step  which  would 
be  used  for  ideas  on  the  next  phase  but  could  be  thrown  away  after  having 
served  its  purpose.  This  approach  enabled  the  development  to  be  completed 
within  the  project  time  constraints  (9  months  from  design  to  implementation). 
Along  the  same  lines,  the  lack  of  fault  tolerance  requirements  minimized 
the  need  for  recovery  capability,  error  diagnostics,  etc.  and  since  it 
was  not  operational  software,  the  system  did  not  need  to  be  user-friendly 
beyond  the  point  at  which  the  developers  could  operate  it.  Anticipating 
future  system  definition  changes,  a  very  modular  (i.e.,  readily  adaptable) 
programming  style  was  used.  Also,  realizing  that  integration  and  in-flight 
testing  would  occur  away  from  the  Intermetrics  development  site  prompted 
special  consideration  to  avoid  a  long  turn-around  time  for  modifications. 
The  division  of  the  software  between  two  companies  wss  not  considered  a 
problem  as  long  as  the  interface  was  established  and  maintained;  each  could 
develop  their  software  independently  provided  that  they  comply  with  the 
protocol.  This  also  facilitated  the  integration  process. 

The  final  group  of  requirements  arose  from  standard  software  development 
practices  and  those  developed  during  the  course  of  the  project.  Prior 
development  experience  and  programming  expertise  enabled  individual  yet 
directed  concurrent  efforts  to  diverge  during  development  and  converge 


to  produce  the  final  system.  For  instance,  on  any  rapidly  changing  project, 
it  is  necessary  to  maintain  an  uncorrupted  (i.e.,  working)  system,  along 
with  exact  knowledge  of  the  current  state-of-the-wor Id  (i.e.,  configuration 
management);  these  tasks  were  facilitated  by  the  small  staff  and  good  communi¬ 
cation.  It  was  also  recognized  that,  while  documentation  wasn't  a  major 
deliverable,  the  only  way  to  maintain  current  information  on  project  details 
was  through  decent  documentation  practices.  The  fact  that  at  any  given 
time  only  a  portion  of  the  development  team  would  be  on-site  to  locate 
problems  and  that  a  complementary  portion  of  the  team  would  be  "back  home" 
to  initiate  corrections  reinforced  the  need  for  documentation  so  that  everyone 
would  have  an  overall  understanding  of  the  software. 


3. 3. 1.1. 2  Methodology 

The  CFPD  software  was  developed  and  maintained  in  several  phases 
for  several  reasons: 

a.  To  divide  a  large  task  into  more  manageable  parts;  this  incremental 
development  aided  the  design,  coding,  testing  and  verification 
of  the  system. 

b.  To  establish  milestones  which  enabled  tracking  of  the  project. 

c.  By  necessity  due  to  the  hardware  involved  (e.g.,  hardware  availabil¬ 
ity,  the  operational  versus  developmental  environments). 


Development  on  the  Interaetrics,  Inc.  PDP-11/70: 

Development  began  in  the  PDP-11/70  under  RSX.  The  CFPD  task  was 
initially  divided  into  smaller,  logical,  manageable  areas:  display,  computa¬ 
tional,  and  data  collection.  Each  member  of  the  developmental  team  worked 
on  a  specific  area  with  overlap  into  all  other  areas.  Each  was  responsible 
for  developing  specific  portions  of  the  software,  eventually  merging  it 
with  the  complete  system  during  integration. 

From  the  functional  specification,  an  initial  design  specification 
was  produced  using  SDDL,  Software  Design  and  Documentation  Language;  algorithms 
were  developed  and  the  interfaces  between  areas  were  established.  During 
the  design,  certain  elements  were  prioritized: 

a.  Functionality  (system  operated  according  to  specifications) 

b.  Reliability  (absence  of  bugs) 

c.  Speed  (the  integrated  system  needed  to  function  in  real-time) 

d.  Space  (the  integrated  system  needed  to  fit  on  the  computer) 

e.  Modifiability  (need  for  direct  accessability  to  variables,  etc.) 

f.  Documentation 

g.  Fault  tolerance  (at  least  a  minimal  amount  of  information) 

Also  at  this  time,  operational  specifications  were  evolved,  also 
using  SDDL,  and  informal  design  reviews  were  held.  Knowing  that  the  design 


specifications  were  high-level  and  that  there  was  a  high  probability  of 
future  system  definition  changes,  a  very  modular  (i.e.,  readily  adaptable) 
programming  style  was  dictated. 


Tested  software  was  maintained  in  a  specified  area  on  the  PDP-11/70. 
Access  to  this  area  was  not  restricted;  instead  communication  between 
developers  was  sufficient  to  guarantee  the  integrity  of  the  system  during 
module  testing.  As  a  result,  there  existed  a  current  working  version  of 
the  system  at  any  given  time. 


Testing  of  software 

For  module  testing  and  integration,  various  mechanisms  were  developed 
either  specifically  for  the  task  or  by  modifying  existing  tools.  They 
provided  the  means  to  exercise  the  computational,  display  and  recorder 
software  and  served  in  varying  degrees  to  simulate  the  integrated  CFPD 
system. 


Transfer  to  the  PDP-11/44  system 

At  this  time,  final  preparations  were  made  to  utilize  the  PDP-11/44 
as  the  operational  system;  all  CFPD  tasks  which  vould  be  performed  during 
flight  testing  were  made  consistent  with  the  system  specifications.  Inter- 
metrics'  tested  portion  of  the  CFPD  software  was  transferred  to  the  PDP-11/44 
system  via  a  bootable  magnetic  tape  and  the  capability  of  down-loading 
the  PS-300  with  the  flight  plan  was  also  accomplished  in  preparation  for 
the  flight  tests. 


System  integration 

The  final  system  integration  with  the  6ensor  software  was  performed 
at  Intermetrics;  all  recognizable  bugs  were  removed  and  a  bootable  system 
magnetic  tape  was  created.  The  actual  integration  tests  were  performed 
on-site  at  Calspan  with  minimal  problems. 


System  tests 

During  the  intial  testing  of  the  system,  many  modifications  were 
requested  as  changes  in  the  implementation  and  the  concept  were  mandated. 
As  a  result  of  the  various  design  considerations,  much  of  the  "fine  tuning" 
had  been  anticipated  and  corrections  could  be  made,  at  times  within  seconds 
of  the  request.  Despite  the  on-site  modifications  to  the  software,  a  current 
(albeit  uneven)  operational  software  specification  was  produced. 


3. 3. 1.2  Software  Description 

The  CFPD  software  system  provides  the  computer  processing  for  presenta- 
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tion  of  the  Command  Flight  Path  (CFPD)  and  conventional  Symbology  for  normal 
(non-tactical)  IMC  flight  through  the  following  flight  phases: 

Take-off 

Cruise  (including  turns  and  altitude  changes) 

Approach  through  flare. 

All  phases  were  pre-determined  and  programmed  with  no  provision 
for  online,  inflight  modifications  to  the  loaded  flight  plan  other  than 
selection  of  various  flight  plan  segments.  Flight  path  "loops"  were  supported, 
with  the  selection  of  whether  to  exit  or  continue  in  the  loop  under  operator 
control  (via  modification  of  the  flight  plan  routing). 

The  CFPD  software  also  provided  for  the  display  of  conventional 
VSD  and  HSD  symbology.  This  display  commanded  the  same  flight  plan  used 
by  the  CFPD  software.  The  same  restrictions  to  flight  plan  modification 
applied. 

During  actual  flight  test,  data  necessary  for  the  post  analysis 
and  evaluation  of  the  flights  (CFPD  and  Symbology)  were  recorded.  In  addition, 
the  display  and  modification  of  program  data  was  supported  from  a  hardcopy 
operator's  terminal. 

The  ability  to  modify  certain  CFPD  (and  Symbology)  parameters,  such 
as  path  segment  dimensions  and  spacing,  velocity  indicator  placement, 
symbol  sensitivities,  etc.,  was  supported  during  preflight  loading,  and 
in  most  cases,  during  actual  flight. 

A  "Restart"  Capability  was  provided  which  supported  the  resetting 
of  the  flight  test  data  gathering  to  the  current  aircraft  position.  This 
function  was  utilized  to  pick  up  the  flight  test  at  a  somewhat  arbitrary 
point  in  case  of  an  unintentional  deviation  from  the  flight  plan  (ATC, 
traffic,  birds,  system  hiccup,  etc.).  In  addition,  the  "filing"  of  the 
aircraft  at  an  arbitrary  location  in  virtual  space  was  provided,  in  essence 
moving  the  virtual  space  along  with  the  aircraft. 

The  TIFS  CFPD  software  system  consisted  of  six  major  modules — 

Sensor,  Sequencer,  Recorder,  Operator,  Data  base,  and  Format.  The  first 
four  modules  reside  as  separate  tasks  in  the  PDP-11,  the  Database  Module 
was  a  shared  data  area  in  PDP-11  memory,  and  the  Format  module  executed 
in  the  PS-300.  The  following  sections  describe  the  functionality  of  the 
six  software  modules  and  their  interrelationships. 


3. 3. 1.2.1  Sensor  Module 

The  Sensor  Module  software,  developed  by  Calspan,  contained  a  number 
of  special  features  and  mode  control  options  to  facilitate  the  evaluation 
of  the  CFPD  concept  and  to  provide  as  accurate  (and  current)  guidance  m.a 
navigation  data  as  possible  from  the  available  sensors.  In  particular, 
this  software  operated  in  one  of  two  main  modes — the  flight  mode  or  the 
ground  simulation  mode.  In  either  case,  the  general  processing  functions 


were  the  same  except  that  in  the  ground  simulation  mode  additional  analog 
data  were  input  through  the  A/D  channels  from  the  ground  simulation  computers 
and  an  INS  simulation  was  also  performed  in  this  subprogram.  In  addition, 
an  ILS  simulation  was  implemented. 

Further  information  regarding  the  Sensor  Module  is  contained  in 
Section  3.3.2. 

3. 3. 1.2. 2  Sequencer  Module 

The  Sequencer  Module  was  responsible  for  the  generation  and  update 
of  the  graphics  displays.  As  such,  its  execution  was  tightly  coupled  to 
the  Sensor  Module,  executing  whenever  the  system  was  in  run  mode  and  data 
were  available,  the  Sequencer  also  determined  the  data  to  be  recorded  by 
the  Recorder  Module.  The  functions  provided  by  the  Sequencer  Module  are 
described  in  the  following  paragraphs.  In  addition,  the  Sequencer  major 
operational  modes  are  described. 

a.  Initialization 

During  initial  program  load,  the  Sequencer  module  was  responsible 
for  "filing"  the  flight  plan  and  down-loading  the  PS- 300.  Filing 
the  flight  plan  entailed  converting  certain  parameters  in  the 
Database  flight  plan  to  more  convenient  units  and  computing 
other  derived  data,  e.g.,  path  segment  length,  roll  in  and  roll 
out  points,  center  of  turns,  etc. 

The  PS-300  was  down-loaded  from  both  a  predefined  program  tape 
and  program  code  generated  as  a  function  of  the  flight  plan 
(see  Format  Module).  The  PS- 300  software  generated  by  the  Sequencer 
Initialization  function  provided  the  command  flight  path  and 
runway  outlines  for  the  CFPD  displays. 

b.  State  Analysis 

The  State  Analysis  function  of  the  Sequencer  Module  computed 
the  ownship  status  relative  to  the  flight  plan  contained  in 
the  Database  Module.  This  task  consisted  of  determining  which 
part  of  the  command  flight  path  the  aircraft  was  currently  on 
(by  geometric  projection).  The  Command  Position  was  also  computed 
based  on  the  previous  command  position,  delta  time,  and  command 
velocities  and  accelerations.  Finally  the  location  of  the  Velocity 
Indicator  was  determined  as  a  function  of  the  ownship' s  projected 
position  on  the  command  flight  path,  the  distance  from  the  ownship 
projected  position,  Command  Position  (if  coupled),  and  velocity 
error. 

The  State  Analysis  had  a  secondary  function  of  determining  and 
updating  the  Sensor  Module's  control  parameters.  These  parameters 
were  based  on  information  contained  in  the  flight  plan  and  deter¬ 
mined  the  current  flight  mode,  sensor  usage  (ILS,  INS,  etc.), 
and  current  runway  data. 
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A  special  mode,  called  Restart,  was  supported  by  the  State  Analyzer 
function.  Given  a  starting  point  (beginning  of  a  flight  plan 
route),  the  State  Analyzer  searched  for  the  current  location 
of  the  aircraft  relative  to  the  flight  plan.  This  mode  was 
used  to  initialize  prior  to  a  test  run  and  for  restarting  at 
an  arbitrary  location. 

c.  Display  Update 

The  Display  Update  function  utilized  the  information  supplied 
by  the  Sensor  Module  and  State  Analyzer  function  of  the  Sequencer 
Module  to  compute  and  format  the  PS-300  display  update.  Various 
rotation  matrices  and  transformations  were  computed.  This  data 
were  then  converted  to  PS-300  internal  binary  format  and  transmitted 
via  the  PS- 300  support  routines  to  the  PS- 300. 

d.  Data  Send 

The  Recorder  Module  was  data  insensitive;  it  was  not  aware  of 
what  it  was  storing  on  tape.  As  such,  the  Data  Send  function 
of  the  Sequencer  Module  was  responsible  for  determining  the 
data  to  be  recorded  during  runtime,  formatting  the  data  into 
Send/Receive  message  packets,  and  sending  the  data  to  the  Recorder 
Module.  This  software  also  controlled  the  frequency  at  which 
the  data  is  recorded.  A  three  Hz  rate  was  used  during  flight 
test. 

e.  Operational  Modes 

The  Sequencer  Module  supported  three  major  operational  modes— Live 
Sensors. 

1.  Live  Sensors  Mode— When  operating  in  Live  Sensors  mode, 
the  Sequencer  depended  on  the  Sensor  Module  for  its  input 
data.  Sequencer  activation  was  dependent  on  and  synchronized 
with  Sensor  software  execution.  This  was  the  mode  under 
which  the  Sequencer  operated  during  Ground  Simulation  and 
Flight . 

2.  Auto-track  Mode— Aut o-track  Mode  provided  a  built-in  test 

and  demonstration  capability.  During  this  mode  of  operation 
the  Sequencer  did  not  utilize  Sensor  generated  data.  Instead, 
the  data  computed  by  the  State  Analyzer  function  of  the 
Sequencer  were  used  as  ovnship  data.  In  particular,  the 
ovnship  location  was  set  to  the  preceding  cycle's  Command 
Position.  The  ovnship  attitude  was  set  equal  to  the  attitude 
computed  for  the  Velocity  Indicator.  Other  values  were 
derived  (ILS)  or  estimated  (angle-of-attack) .  This  mode 

was  used  extensively  during  software  development  at  Intermetrics 
prior  to  total  software  integration. 


3.  Sim-tape  Mode — The  Sequencer  Module  was  also  capable  of 
accepting  pre-recorded  "sensor"  values  froir  digital  magnetic 
tape.  This  mode  was  used  early  in  the  Sequencer  development 
task  as  a  means  to  record  a  flight  using  the  Intermetrics 
F/A-18  simulation  model  and  playback  a  given  flight  for 
testing  purposes.  In  addition,  one  of  the  actual  flight 
tests  (during  which  data  wer,.  recorded  at  fifteen  Hz)  has 
been  used  to  generate  a  Sim-tape  for  demonstration,  providing 
the  capability  to  re-play  an  actual  flight. 

To  support  this  function,  a  software  tool  was  developed 
which  would  accept  a  tape  generated  by  the  Record  Module 
and  reformat  it  for  use  as  a  Sim-tape.  If  desired,  it  would 
be  possible  to  develop  a  program  which  would  take  the  three 
Hz  sampled  data  from  flights,  interpolate  to  a  fifteen  Hz 
frequency,  and  generate  Sim-tapes  for  all  of  the  flights. 


3. 3. 1.2. 3  Recorder  Module 

The  performance  of  the  pilots  using  the  CFPD  display  versus  the 
Symbology  display  was  evaluated  off-line  using  data  recorded  during  the 
actual  test  flights.  The  Recorder  Module  provided  this  data  recording 
function.  The  Recorder  is  capable  of  receiving  data  message  (via  the  RSX-11S 
Send  Data  mechanism)  from  any  of  the  other  PDP-11  tasks  for  storage  on 
digital  magnetic  tape  (the  Sensor  Module  did  not  utilize  this  capability). 
No  processing  or  conditioning  of  the  data  received  by  the  Recorder  is  per¬ 
formed.  The  data  are  recorded  on  the  tape  "as  is." 

The  Send  Data  facility  was  chosen  instead  of  using  the  Database 
Module  to  transmit  data  to  the  Recorder  Module  to  avoid  possible  data  integrity 
and  synchronization  problems.  The  Recorder  can  then  operate  as  a  background 
task,  somewhat  asynchronously  with  the  Sensor  and  Sequencer  Modules. 

The  actual  data  recorded  during  flight  tests  included  the  actual 
ownship  "state  vector”  and  certain  command  values.  These  data  were  passed 
to  the  Recorder  Module  at  a  3  Hz  sampling  rate. 


3. 3. 1.2. 4  Operator  Module 

In  order  to  provide  online  system  monitoring  and  control  without 
impacting  the  realtime  software  functions,  the  Operator  Module  was  designed 
and  developed  as  a  separate  task  in  the  PDP-11.  All  data  contained  in 
the  Database  Module  are  accessible  by  the  Operator  Module. 

To  provide  a  general  control  and  debug  capability,  the  Operator 
software  supported  a  memory  display/modify  command  which  allowed  the  display 
and  modification  of  arbitrary  memory  locations  in  the  Database.  Multiple 
data  formats  were  supported  (integer,  real,  logical,  octal).  In  addition, 
special  commands  were  added  to  provide  a  friendlier,  less  error  prone  interface 
for  common  system  functions.  These  included  display  format  selection, 


system  mode  selection,  current  ownship  state  display,  test  2  (see  Sensor 
Module)  setup  and  control,  and  test  engineer  annotation  of  the  data  recording. 

The  Operator  Module  also  provided  the  capability  to  program  the 
PS-300  from  the  operator's  console.  This  function  was  provided  by  a  system 
mode  handshaking  protocol  between  the  Operator  Module  and  the  Sequencer 
Module.  The  Operator  task  notified  the  Sequencer  through  a  system  mode 
that  a  statement  located  in  the  Database  was  available  for  transmission 
to  the  PS-300.  The  Sequencer  then  transmits  the  statement  to  the  PS-300 
and  resets  the  system  mode. 


3. 3. 1.2. 5  Database  Module 

The  Database  Module  was  a  shared  data  area  located  in  PDP-11  memory. 
The  Sensor,  Sequencer,  and  Operator  Modules  mapped  to  this  area  for  data 
communication  and  control.  The  Database  provided  storage  for  the  display 
parameters  and  buffers,  flight  plan,  flight  state.  Sensor  Module  control 
and  output,  and  the  global  system  status. 

Initial  values  were  provided  for  much  of  the  data  stored  in  the 
Database  Module.  This  data  (stored  on  the  system  boot  tape)  consisted 
of  the  flight  plan,  display  parameters,  and  sensor  filtering  coefficients. 


3. 3. 1.2. 6  Format  Module 

The  Format  Module  consisted  of  the  programming  dovn-loaded  into 
the  PS-300  by  the  PDP-11.  This  code  consisted  of  a  "static"  portion  which 
was  independent  of  the  flight  plan  contents  and  a  "dynamic”  portion  which 
reflects  the  preprogrammed  flight  plan.  The  static  portion  was  stored 
on  magnetic  tape  and  copied  into  the  PS-300  by  the  PDP-11  during  initial 
program  load.  The  dynamic  code  was  generated  by  the  Sequencer  Module  based 
on  the  flight  plan  and  also  dovn-loaded  during  program  load. 

The  Format  program  contained  the  entire  graphical  image.  This  included 
the  complete  command  flight  path  and  runway  dravings.  The  data  passed 

to  the  PS-300  during  runtime  consisted  only  of  the  current  values  for  the 
image's  degrees  of  freedom.  For  example,  to  move  and  orient  the  Velocity 
Indicator,  the  PDP-11  (Sequencer  Module)  transmitted  the  current  location 

(latitude,  longitude,  altitude)  relative  to  the  eyepoint  and  the  Velocity 

Indicator's  current  attitude  (roll,  pitch,  heading).  The  lines  which  made 
up  the  actual  Velocity  Indicator  image  were  NOT  transmitted. 

The  following  sections  describe  the  display  formats  provided  by 

the  Format  Module.  These  formats  included  the  Command  Flight  Path  Display 
Vertical  and  Horizontal  Situation  Displays  and  the  Symbology  Vertical  and 
Horizontal  Situation  Display.  The  Symbology  displays  were  modeled  after 
the  current  F/A-18  NAV  and  approach  mode  HUD  and  HSD  display  formats. 


CFPD  Vertical  Situation  Display 


The  Vertical  Situation  Display  was  presented  with  a  fifty  degree 
field  of  view  (FOV)  and  consisted  of  three  major  elements— Flight  Path, 
Velocity  Indicator,  and  Earth  Plane.  These  elements  are  described  below. 

a.  Flight  Path 

The  flight  path  consisted  of  path  plates  which  appeared  to  be 
rectangular  plates  100*  by  600'  with  a  centerline.  (Mote  that 
rectangular  plates  viewed  at  non-perpendicular  angles  appear 
as  trapezoids  due  to  the  perspective  transformation.)  These 
plates,  placed  300'  apart,  center  to  center,  defined  the  command 
flight  path.  The  plates  were  not  necessarily  parallel  to  the 
earth  plane,  as  they  were  "banked"  during  command  turns  and 
"pitched"  during  command  ascents  and  descents. 

b.  Velocity  Indicator 

The  command  airspeed  was  represented  by  a  3-D  wireframe  aircraft 
with  which  the  test  aircraft  was  to  "fly  formation."  Deviations 
from  the  command  velocity  were  indicated  by  a  corresponding 
displacement  of  the  velocity  indicator  relative  to  ownship. 
In  addition,  the  command  velocity  driving  the  velocity  indicator 
could  be  coupled  to  the  Command  Position,  or  "How  goes  it"  circle. 
The  instantaneous  command  velocity  would  then  be  the  base  command 
velocity  (per  the  flight  plan)  plus  or  minus  a  velocity  delta 
which  would  bring  the  ownship  back/ up  to  the  Command  Position. 
Velocity  errors  which  would  allow  the  ownship  to  overtake  the 
velocity  indicator  resulted  in  the  positioning  of  a  blinking 
velocity  indicator  at  a  fixed  distance  of  eight  hundred  feet 
in  front  of  the  ownship.  Velocity  errors  which  would  allow 

the  velocity  indicator  to  disappear  on  the  horizon  result  in 

a  maximum  distance  for  the  velocity  indicator  of  four  thousand 
•  feet  in  front  of  the  ownship.  These  artificial  limits  were 
imposed  to  prevent  losing  sight  of  the  velocity  indicator. 
The  current  position  relative  to  the  command  position  could 

still  be  determined  by  observing  the  horizontal  situation  display. 

The  velocity  indicator  position  and  size  were  selectable  parameters 
and  could  be  changed  easily  to  meet  pilot  preference.  The  velocity 
indicator  "flies”  alongside  of,  and  is  oriented  with,  the  command 
flight  path.  The  majority  of  the  test  flights  were  flown  with 
the  velocity  indicator  at  a  distance  of  one  hundred  and  fifty 

feet  above  the  flight  path  and  three  hundred  feet  to  the  left 
of  flight  path  centerline.  The  final  version  of  the  TIFS  CFPD 
software  permitted  the  operator  to  select  velocity  indicators 
which  flew  on  the  left  or  right  side  of  the  command  flight  path. 
Additionally,  a  formation  of  three  velocity  indicators  could 
be  called  up,  whereby  the  ovnship  would  fly  the  "slot"  position 
in  a  diamond.  The  velocity  indicator  on  most  flights  was  four 
hundred  fifty  feet. 
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c.  Earth  Plane 


The  earth  plane  provided  a  textured  representation  of  the  ground. 
The  apparent  size  and  detail  of  this  texturing  corresponded 
to  the  aircraft's  location  and  attitude.  The  lines  comprising 
the  earth  plane  were  spaced  at  an  interval  of  fifteen  thousand 
feet.  In  addition,  a  runway  representation  with  standard  markings 
was  displayed  for  use  during  take-off  and  landing.  The  runway 
was  at  the  same  perspective  as  the  corresponding  earth  plane. 
The  dimensions  were  six  hundred  feet  wide  by  nine  thousand  one 
hundred  twenty-five  feet  long. 


CFPD  Horizontal  Situation  Display 

The  horizontal  situation  of  the  CFPD  display  consisted  of  three 
elements.  These  elements  were  the  Command  Ground  Track,  Current  Position, 
and  Command  Position. 

a.  Command  Ground  Track 

The  command  ground  track  defined  by  the  flight  plan  was  represented 
as  a  single  solid  line.  Vhile  in  the  vicinity  of  the  airport, 
a  runway  representation  is  displayed.  The  scale  used  for  depicting 
the  map  was  under  operator  control.  The  scale  used  during  the 
flight  test  corresponded  to  a  square  map  presentation  60,000 
feet  on  a  side. 

b.  Current  Position 

The  current  location  of  the  aircraft  was  shown  by  a  small  plan 
view  or  shadow  image  of  the  aircraft,  placed  relative  to  the 
cosnsand  ground  track.  The  shadow  image  was  equivalent  to  three 
thousand  eight  hundred  fifty  feet  in  length.  Its  orientation 
was  fixed,  with  the  underlaying  elements  rotating  as  per  the 
ownship  heading. 

c.  Command  Position 

During  flight  plan  segments  which  commanded  that  the  aircraft 
should  be  at  a  certain  location  at  a  certain  time,  the  corresponding 
position  was  displayed  as  a  small  circle  on  the  command  ground 
track.  This  circle  was  visible  during  flight  plan  segments 
which  command  a  given  ground  speed,  and  was  not  displayed  during 
segments  in  which  the  command  velocity  was  an  airspeed.  The 
circle  had  a  radius  of  two  thousand  feet. 


Symbology  Vertical  Situation  Display 

The  Vertical  Situation  Display  consisted  of  twelve  parametric  display 
elements.  These  elements  are  detailed  below. 
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a.  Heading 


The  aircraft's  true  heading  was  indicated  by  a  moving  tape  scale 
at  the  top  of  the  VSD  display. 

b.  Air  Speed 

The  aircraft's  indicated  air  speed  was  displayed  as  a  digital 
readout  on  the  left  side  of  the  display.  This  value  was  enclosed 
in  a  box,  the  top  of  which  was  in  line  with  the  Altitude  readout 
box. 

c.  Altitude 

Barometric  altitude  vas  displayed  as  a  digital  readout  enclosed 
in  a  box.  The  box  was  on  the  right  side  of  the  display,  in 
line  with  the  Air  Speed  readout. 

d.  Vertical  Velocity 

A  digital  readout,  directly  above  the  Altitude  box,  was  used 
to  show  the  aircraft's  vertical  velocity  in  feet  per  minute. 

e.  Velocity  Vector 

A  velocity  vector  symbol  vas  used  to  display  the  point  towards 
which  the  aircraft  was  currently  flying.  The  Flight  Path/Pitch 
Ladder,  Angle  of  Attack  bracket,  ILS  needles,  and  Course  Indicator 
were  displayed  relative  to  the  Velocity  Vector  and  would  move 
around  with  it. 

If  the  pilot  desired,  the  Velocity  Vector  could  be  caged  in 
either  the  horizontal  (typical)  or  vertical  (atypical)  axes. 

f.  Flight  Path/Pitch  Ladder 

The  vertical  flight  path  angle  of  the  aircraft  vas  indicated 
by  the  position  of  the  Velocity  Vector  on  the  Flight  Path/Pitch 
Ladder.  The  aircraft  pitch  attitude  vas  indicated  by  the  position 
of  the  aircraft  Waterline  mark  with  respect  to  the  Flight  Path/Pitch 
Ladder.  Aircraft  roll  vas  indicated  as  the  rotation  of  the 
Flight  Path/Pitch  Ladder  around  the  Velocity  Vector.  Pitch 
lines  were  in  five  degree  increments;  above  the  horizon  lines 
were  solid,  below  the  horizon  lines  were  dashed. 

g.  Waterline  Mark 

A  waterline  symbol  vas  located  on  the  display  to  give  a  zero 
pitch  reference  mark  for  the  pilot.  This  symbol  could  be  removed 
at  the  discretion  of  the  pilot. 
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h.  Bank  Angle  Scale 


A  plus  to  minus  45  degree  bank  scale  was  located  along  the  bottom 
of  the  display.  Major  tick  marks  were  at  15  degree  intervals, 
with  a  minor  tick  mark  at  plus  and  minus  5  degrees. 

i.  Angle  of  Attack  Bracket 

An  AOA  bracket  was  located  along  the  left  side  of  the  Velocity 
Vector  during  Approach.  The  center  of  the  bracket  was  intended 
to  indicate  the  optimum  AOA  for  approach.  As  this  was  never 
determined  for  the  T1FS  aircraft,  the  pilot  was  told  to  ignore 
this  symbol.  In  later  flights,  the  symbol  was  actually  removed. 

j.  Course  Indicator 


Course  steering  data  were  displayed  as  an  arrow  showing  a  horizontal 
indication  relative  to  the  Velocity  Vector.  The  rotation  of 
the'  arrow  indicated  relative  direction  of  the  command  course, 
while  the  offset  of  the  arrow  from  the  Velocity  Vector  indicated 
course  lateral  deviation.  The  scaling  used  during  flight  tests 
was  2000  feet  per  dot.  This  display  construct  was  very  similar 
to  the  CDI  elements  of  a  mechanical  HSI. 

k .  DME  Readout 

Range  to  the  waypoint  (DME)  was  displayed  as  a  digital  readout 
on  the  right  side  of  the  display. 

l.  ILS 

ILS  elevation  and  azimuth  needles  were  displayed  relative  to 
the  Velocity  Vector.  The  ILS  display  was  only  visible  during 
Approach. 


Symbology  Horizontal  Situation  Display 


The  Horizontal  Situation  Display  consisted  of  five  display  elements. 
These  elements  are  detailed  below.  In  addition  to  the  display  elements, 
the  pilot  could  specify  whether  a  Heading  Dp,  Ground  Track  Dp,  or  North 
Dp  display  orientation  was  desired. 

a.  Heading 

The  true  Heading  of  the  aircraft  was  indicated  by  a  heading 
marker  (lubber  line)  on  the  periphery  of  the  compass  rose  and 
a  digital  readout  to  the  left  of  the  center  aircraft  symbol. 
The  orientation  of  the  aircraft  symbol  in  the  center  of  the 
display  corresponded  to  the  heading  marker. 
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b.  Ground  Track 


The  Ground  Track  of  the  aircraft  was  indicated  by  a  Ground  Track 
pointer  on  the  periphery  of  the  compass  rose.  This  marker  consisted 
of  a  diamond  with  a  short  "tail." 

c.  Ground  Speed 

The  Ground  Speed  of  the  aircraft  was  displayed  as  a  digital 
readout  to  the  right  of  the  center  aircraft  symbol. 

d.  Course 

The  Course  heading  of  the  current  flight  plan  segment  was  indicated 
by  a  Course  marker  on  the  periphery  of  the  compass  rose  and 
a  digital  readout  in  the  upper  right  hand  corner  of  the  display. 
The  course  pointer  consisted  of  a  triangular  head  with  an  inscribed 
circle  and  dot  and  a  rectangular  tail  at  the  reciprocal  of  the 
course. 

e.  DUE 

The  range  to  the  waypoint  was  displayed  after  the  Course  heading 
readout. 


3. 3. 1.2. 7  Operational  Data  Flow 

The  Sensor  Module  received  the  raw  sensor  values  through  the  Lab 
peripheral  accelerator  (LPA-11K)  hardware.  The  Sensor  software  was  notified 
of  data  availability  through  the  posting  of  an  RSX-11S  "significant  event” 
by  the  LPA-11K  support  routines  (provided  by  DEC).  After  processing  this 
data,  the  Sensor  Module  loaded  the  data  into  the  Database,  notified  the 
Sequencer  Module  that  new  data  were  available  through  another  significant 
event,  and  "went  to  sleep"  waiting’ for  new  sensor  data. 

The  Sequencer  Module  utilized  the  data  placed  in  the  Database  by 
the  Sensor  software  to  update  the  displays.  As  the  Sequencer  was  at  a 
lower  priority  than  the  Sensor  Module,  but  higher  than  any  of  the  other 
tasks,  the  Sequencer  executed  after  the  Sensor  Module  suspended  itself. 

The  display  update  computed  by  the  Sequencer  software  was  transmitted 
to  the  PS-300  via  the  RSX-11S  standard  DMR-11  device  driver.  If  at  a  three 
Hz  interval,  the  Sequencer  also  transmitted  (via  the  RSX-US  supported 
Send  Data  mechanism)  selected  data  values  to  the  Recorder  Module.  The 
Sequencer  then  suspended  itself  and  vaited  for  the  next  data  ready  significant 
event  from  the  Sensor  software. 


3 .3. 1.2. 8  Resource  and  Performance  Statistics 

The  Intermetrics  software  contribution  consisted  of  approximately 


18,000  lines  of  PDP-11  Ratfor/Fortran  source  code  (12,500  if  comments  were 
removed)  and  1,000  lines  of  PS-30C  source  developed  in  about  11  manmonths. 
The  PS-300  internal  code,  including  the  computer  generated  command  flight 
path  for  the  flight  tests,  required  580, 400  bytes  of  PS- 300  memory.  The 
Database  Module  required  7,800  words  of  PDP-11  memory,  while  the  Sequencer 
Module  code  required  33,500  words.  While  the  software  system  was  designed 
to  support  both  the  CFPD  and  Symbology  display  formats,  plus  data  recording 
and  online,  operator  interfacing,  approximately  720  lines  of  source  code 
and  2,200  words  of  memory  can  be  identified  as  Symbology  specific.  Therefore, 
the  CFPD  format  can  be  considered  to  require  17,280  lines  of  Ratfor/Fortran 
source  code  and  39,100  words  of  memory.  The  reader  is  cautioned,  however, 
against  using  these  statistics  as  an  estimate  of  flightworthy  operational 
software  requirements  due  to  the  design  goals  and  objectives  of  this  project 
(e.g.,  rapid  prototype,  minimal  use  of  programmers,  high  level  maintainability; 
see  Section  3. 3. 1.1). 

The  runtime  system  executed  during  runtime  at  a  15  Hz.  rate  on  a 
PDP-11/44  with  floating  point  processor  using  the  RSX-llS  Version  4.0  operating 
system.  The  CFPD  software  was  shown  to  be  capable  of  a  20  Kz.  cycle  time, 
but  the  Symbology  software  was  not  able  to  attain  this  rate.  It  is  expected 
that  the  PDP-11  to  PS-300  interface  through  the  DMR-11AE  DECnet  interface 
was  the  primary  limiting  factor,  but  this  was  not  shown  conclusively. 


3.3.2  Arv in/ Cal span' s  Contribution 

The  purpose  of  the  CFPD  sensor  software  was  to  provide  the  interface, 
as  well  as  the  requisite  data  processing  functions,  between  the  real  world 
TIFS  aircraft-related  sensor  systems  and  the  display  software.  The  primary 
function  was  to  provide  a  set  of  smoothed  and  processed  sensor  input  data 
to  the  display  software  that  defined  the  position,  attitude  and  velocities 
of  the  aircraft  relative  to  an  earth-referenced  coordinate  system  (the 
guidance  and  navigation  data)  as  well  as  other  aircraft-related  flight 
parameters.  These  data  included  input  from  an  Inertial  Navigation  System 
(INS),  an  ILS  receiver,  a  radar  altimeter,  the  TIFS  Air  Data  Computer, 
TIFS  Inertial  Sensors  and  other  signals,  and  the  Workload  Assessment  Device 
(WAD).  A  secondary  function  was  to  provide  the  required  test  functions, 
mode  control,  and  sequence  logic  for  the  planned  CFPD  flight  evaluation 
phases  (e.g.,  take-off,  cruise  and  approach/landing)  in  either  a  Flight 
or  a  Ground  Simulation  Mode. 

The  CFPD  sensor  software  was  developed  by  Calspan  to  satisfy  the 
functional  requirements  defined  in  the  CFPD  Software  Specification.  This 
specification  was  written  jointly  by  Calspan  and  Intermetrics  early  in 
the  program  to  serve  as  a  guide  during  software  development,  as  well  as 
to  satisfy  the  communication  requirements  of  the  software  design  and  docu¬ 
mentation  process.  Calspan  was  responsible  for  the  sensor  software  part 
of  the  specification. 

The  sensor  software  was  developed  at  Calspan  using  a  PDP-11/45  computer 
with  a  P.SX-llM  operating  system.  The  software  source  code  was  then  transferred 
to  Intermetrics  where  it  was  integrated  with  the  display  and  CFPD  system 


software  to  run  under  the  RSX-llS  operating  system  on  the  PDP-11/44  computer. 
Because  of  task  size  constraints,  the  sensor  software  resides  as  a  separate 
but  high  priority  task  in  the  system.  Data  communication  between  the  tasks 
is  through  a  resident  common  region,  referred  to  below  as  the  Global  Database. 


3. 3. 2.1  General  Sensor  Software  Description 

The  sensor  software  resided  as  a  separate  task  in  the  overall  CFPD 
software.  The  program  provided  the  real-time  interface  between  the  TIFS 
aircraft-related  sensor  systems  and  the  display  software.  Its  primary 
function  was  to  provide  processed  sensor  input  data  to  the  display  software 
that  defined  the  position,  attitude  and  velocities  of  the  aircraft  relative 
to  an  earth-referenced  coordinate  system  as  well  as  other  aircraft-related 
flight  parameters  such  as  air  data.  A  secondary  function  was  to  provide 
the  required  test  functions,  mode  control  and  sequence  logic  for  the  planned 
CFPD  flight  evaluation  phases  in  either  a  Flight  or  Ground  Simulation  Mode. 

All  sensor  data  transfers  to  the  PDP-11/44  were  via  the  LPA11-K 
microprocessor  peripheral  accelerator.  The  sensor  software  controlled 
the  LPA11-K  through  the  use  of  standard  LPA11-K  FORTRAN  support  routines 
provided  by  DEC  as  part  of  the  RSX-llM  or  11S  operating  systems.  The  local 
databases  contained  all  data  and  control  parameters  passed  between  the 
sensor  subprograms,  the  LPA11-K  and  the  support  routines.  The  Global  databases 
contained  the  control  and  data  passed  between  the  sensor  software  and  the 
display  software. 

The  sensor  software  also  provided  the  real-time  synchronization 
between  the  sensor  inputs  from  LPAll-K  and  the  rest  of  the  display  software. 
Since  all  sensor  data  transfers  to  main  memory  were  controlled  by  the  LPAll-K, 
sychronization  was  achieved  by  using  the  real  time  clock  in  the  LPAll-K 
to  control  the  update  rate  of  the  PDP-11/44  software.  This  was  accomplished 
by  initiating  the  sensor  update  loop  at  the  completion  of  each  A/D  data 
sweep.  At  the  completion  of  the  sensor  processing  calculations,  an  event 
flag  was  set  to  synchronize  the  display  software.  The  final  update  rate 
used  was  fifteen  updates  per  second. 


3. 3. 2. 1.1  Sensor  Software  Modes 

The  sensor  software  contained  a  number  of  special  features  and  mode 
control  options  to  facilitate  the  evaluation  of  the  CFPD  concept  and  to 
provide  as  accurate  (and  current)  guidance  and  navigation  data  possible 
from  the  available  sensors.  The  main  mode  control  and  submode  control 
of  the  sensor  software  was  provided  by  the  SENCTL  database  which  was  controlled 
by  the  display  software.  Prestored  data  needed  for  navigation  purposes 
was  also  provided  by  this  database.  For  instance,  a  runway  data  vector 
provided  data  for  runway  length,  altitude,  heading,  glide  slope  angle, 
localizer  position,  glide  slope  intercept  position,  etc.,  which  was  used 
in  the  INS/ILS  mixer  processing  functions.  All •  processed  data  to  be  used 
by  the  display  software  was  copied  into  the  SENOUT  database.  This  database 
provided  the  interface  between  all  sensor  software  output  and  the  display 


software. 


The  sensor  software  operated  in  one  of  two  main  modes  -  the  Flight 
Mode  or  the  Ground  Simulation  Mode.  In  either  case,  the  general  processing 
functions  were  the  same  except  that  in  the  Ground  Simulation  Mode  additional 
analog  data  were  inputted  through  the  A/D  channels  from  the  ground  simulation 
computers  and  an  INS  simulation  was  performed  using  this  data.  In  addition, 
an  ILS  simulation  could  be  selected  as  an  option  in  either  the  Flight 
or  Ground  Simulation  Mode. 

Selection  of  one  of  four  primary  modes  (Preflight,  Take-off,  Cruise 
and  Approach)  which  control  the  sensor  software  processing  functions  was 
via  the  SENCTL  database.  The  functional  requirements  and  submode  control 
for  the  Preflight  and  Cruise  Modes  were  straightforward;  however,  for  the 
Take-off  and  Approach  Modes,  the  sensor  software  was  automatically  advanced 
and  latched  through  a  sequence  of  guidance  submodes  for  blending  of  INS, 
ILS  and  TIFS  altitude  and  radar  altimeter  data.  In  addition,  two  Test 
Modes  and  a  Position  Reset  feature  were  provided  to  initialize  or  update 
the  position  of  the  aircraft  at  a  pre-specif ied  location.  The  modes  were 
as  follows. 

a.  Preflight 

In  the  Preflight  Mode,  all  sensor  software  I/O  and  filter  processing 
functions  were  executed,  except  that  the  blending  of  INS,  ILS 
and  radar  altimeter  data  were  disallowed.  The  navigation  calcula¬ 
tions  to  convert  from  geodetic  latitude  and  longitude  (from 
the  INS)  to  Cartesian  coordinates  relative  to  the  runway  reference 
position  were  also  performed.  The  main  purpose  of  this  mode 
was  to  allow  time  to  stabilize  any  dynamic  filters  prior  to 
engagement  of  the  other  modes.  It  could  be  entered  from  any 
other  mode.  The  Test  Mode  and  the  Posicion  Reset  feature  were 
also  functional  in  this  mode. 

b.  Cruise 

All  preflight  processing  functions  were  performed  in  this  mode. 
Aircraft  guidance  in  this  mode  was  provided  solely  by  the  INS 
and  the  TIFS  complementary  filtered  altitude.  It  could  be  entered 
from  any  other  mode. 

c.  Take-off 

Besides  updating  all  Cruise  Mode  processing  functions,  selection 
of  the  Take-off  Mode  activated  the  radar  altimeter  and  TIFS 
complementary  filtered  altitude  mixer  to  generate  a  smoother 
altitude  signal,  whenever  the  appropriate  criteria  were  satisfied. 
Knowing  the  runway  altitude  also  allowed  the  radar  altimeter 
to  continually  calibrate  the  altitude  estimate  from  the  TIFS 
complementary  filter  output.  In  addition,  the  runway  localizer 
capture  logic  was  activated.  For  instance,  the  criteria  for 
localizer  capture  at  take-off  might  be  that  the  aircraft  had 


moved  to  within  +/-  one  hundred  feet  of  the  runway  centerline, 
was  within  +/-  five  degrees  of  runway  heading  and  the  weight 
on  wheel  (WOW)  signal  was  active.  When  the  criteria  were  satisfied, 
a  LCC/INS  lateral  complementary  filter  computation  was  initiated 
and  utilized  for  precise  lateral  position  determination.  These 
data  were  also  used  to  continually  update  the  INS  position  data 
during  the  take-off  roll.  After  lift-off  (airspeed  greater 
than  rotation  speed)  and  transition  (not  WOW),  the  sensor  software 
computations  would  automatically  revert  to  those  in  the  Cruise 
Mode.  In  the  Take-off  Mode,  the  Test  Modes  and  the  Position 
Reset  features  were  functional.  In  addition,  a  special  Take-off 
Position  Reset  function  was  provided  in  this  mode  to  update 
the  INS  at  a  prespecified  take-off  location  on  the  runway. 
Also,  this  mode  could  be  entered  from  any  other  mode. 

Approach/Land ing 

Selection  of  the  Approach  Mode  allowed  a  sequence  of  guidance 
submodes  to  be  entered  which  were  advanced  by  approach  progress. 
In  addition,  all  Cruise  Mode  processing  functions  continued 
to  be  executed  and  the  radar  altimeter/TIFS  complementary  filtered 
altitude  mixer  was  activated  (similar  to  the  Take-off  Mode) 
whenever  the  appropriate  radar  altimeter  capture  criteria  were 
satisfied.  The  guidance  submodes  were  defined  by  the  following 
structure: 

Guidance  Submode  Requirement 

INS  Guidance  Approach  Mode  Selection 

LOC/INS  Guidance  Localizer  Capture 

LOC/Glide  Slope/INS  Guidance  Glide  Slope  Capture 

Flare  -  LOC/INS  Terrain  Altitude < 50' 

Rollout  -  LOC/INS  WOW  set 

Similar  to  the  Take-Off  Mode,  the  INS  and  the  altitude  complementary 
filter  would  be  updated  continually  by  the  ILS  and  radar  altimeter. 
The  ILS  and  INS  data  were  mixed  in  complementary  filter  fashion 
as  were  the  radar  altimeter  and  TIFS  complementary  filtered 
altitude  data,  whenever  the  appropriate  capture  criteria  were 
satisfied.  These  complementary  filters  were  the  same  as  steady- 
state  Kalman  estimators.  At  some  point  during  rollout,  the 
Take-off  Mode  would  automatically  be  engaged  by  the  Sensor  Software 
with  the  localizer  capture.  Also,  this  mode  could  be  entered 
from  any  other  mode,  even  though  the  normal  mode  advancement 
would  be  from  the  Cruise  Mode. 

During  an  approach  and  landing  to  an  actual  runway,  the  trajectory 
of  the  aircraft  is  defined  primarily  by  the  ILS  and  radar  altimeter 
data;  the  INS  merely  performed  a  beam  smoothing  function.  If, 
for  any  reason,  the  ILS  was  off  or  the  appropriate  capture  criteria 
were  not  satisfied,  guidance  was  from  the  INS  and  TIFS  altitude 
data. 


Two  Test  Modes  were  provided  by  the  Sensor  Software.  Both  of 
these  inodes  simply  added  constant  offsets  to  the  position  data 
from  the  INS  and  altitude  complementary  filter  to  initialize 
the  location  of  the  aircraft  at  a  preselected  position.  The 
Test  1  Mode  used  the  initial  position  defined  by  the  runway 
data;  the  Test  2  Mode  used  another  preselected  location  defined 
in  the  SENCTL  database.  The  real  ILS  and  radar  altimeter  were 
automatically  disabled  in  the  Test  Mode,  although  the  ILS  simulation 
could  still  be  enabled.  The  Test  Modes  were  useful  to  initialize 
the  aircraft  at  a  particular  position  for  approach  and  landing 
evaluations  to  a  "virtual"  runway  at  altitude  or  to  simply  initiate 
for  airwork  in  Cruise  to  "find"  the  Command  Flight  Path.  This 
was  achieved  by  "fooling"  the  aircraft  guidance  systems.  Therefore, 
offset  Reset  functions  were  also  provided 

f.  Position  Reset 

This  feature  was  useful  to  update  the  INS  when  the  present  position 
of  the  aircraft  was  known.  It  could  be  invoked  at  anytime  except 
after  localizer  capture  in  Approach  Mode. 

g.  Check-out  Test  Mode 

This  feature  allowed  input  data  from  the  LPAll-K  to  be  replaced 
by  pre-stored  values.  It  was  useful  during  check-out  of  the 
sensor  software. 


3. 3. 2. 1.2  Sensor  Software  Processing  Functions 

The  purpose  of  the  major  sensor  software  functions  was  to  compute 
the  best  estimate  of  the  airplane's  state  vector  (position,  velocity  and 
attitude)  from  the  various  sensor  inputs  with  enough  precision  and  resolution 
so  as  not  to  compromise  the  evaluation  of  the  CFPD  concept. 

The  major  sensor  inputs  were  from  the  INS,  an  ILS  receiver,  a  radar 
altimeter,  TIFS  sensor  data  and  various  signals  from  the  gound  simulation 
computers.  Inputs  from  the  INS  included  horizontal  position  (geodetic 
latitude  and  longitude),  intertial  velocity  (North  and  East  components), 
attitude  (pitch  and  roll)  and  true  heading.  Vertical  guidance  was  from 
the  TIFS  altitude  data  and  from  the  radar  altimeter.  The  ILS  signals  were 
conventional  glide  slope  and  localizer  deviation  errors,  the  TIFS  altitude 
and  vertical  rate  data  were  computed  on  the  TIFS  system  computers  by  blending 
barometric  altitude  and  vertical  acceleration  measurements  in  a  complementary 
filter  fashion.  Other  TIFS  data  included  inputs  from  the  air  data  computer 
and  the  TIFS  pitch  and  roll  attitude  gyros. 

All  analog  signals  from  the  analog-to-digital  (A/D)  converters  could 
be  individually  filtered  to  remove  noise  with  a  first  order  digital  filter. 
The  coefficients  of  the  filter  difference  equations  were  computed  using 


a  Tustin  transformation.  The  filter  break  frequencies  were  individually 
selectable  or  the  filter  could  be  bypassed.  In  the  final  software  configura¬ 
tion,  five  relatively  low  frequency  air  data  signals  were  filtered. 

Similarly,  data  from  the  INS,  which  were  transferred  to  the  computer 
in  a  digital  form,  could  be  selectively  filtered.  In  the  Ground  Simulation 
Mode,  the  data  from  the  INS  were  substituted  by  the  INS  simulation  calcula¬ 
tions.  Options  were  also  available  in  the  sensor  software  to  use  TIFS 
attitude  data  instead  of  the  INS  attitudes.  Early  in  the  CFPD  flight  evalua¬ 
tions  the  filters  were  used  to  eliminate  pitch  angle  jitter  in  the  display 
caused  by  synchro-to-digital  converter  noise.  Later  in  the  program,  the 
attitude  gyro  signals  from  TIFS  were  used  instead  and  the  filters  were 
bypassed. 

The  horizontal  guidance  computations  consisted  of  three  major  func¬ 
tions.  The  functions  are  described  in  the  following. 

a.  INS  Complementary  Filters 

The  purpose  of  the  INS  complementary  filters  was  to  provide 
high  resolution,  short-term,  position  data  (latitude  and  longitude) 
to  the  display  software.  This  was  accomplished  by  blending 
longitude  and  V/E  (East  component  of  velocity)  or  latitude  and 
V/N  (North  component  of  velocity)  in  complementary  filter  fashion 
to  form  composite  longitude  or  latitude  position  measurements. 
The  end  result  was  that  the  low  frequency  information  content 
in  these  composite  parameters  was  from  the  raw  INS  position 

measurements,  whereas  the  high  frequency  content  was  from  the 

more  accurate  velocity  data. 

b.  ILS/INS  Mixer 

The  idea  behind  the  ILS/INS  mixer  was  basically  the  same,  only 
the  geometry  and  the  low  frequency  data  input  were  different. 

In  this  case,  the  position  of  the  airplane  was  defined  relative 
to  the  touchdown  point  on  the  runway  in  terms  of  forward  (RF) 

and  cross  (RC)  range  to  go  in  feet.  The  North  and  East  components 
of  velocity  from  the  INS  were  simply  resolved  into  this  coordinate 
system  as  a  function  of  runway  heading.  During  an  approach 
and  landing,  and  after  localizer  and  glide  slope  capture,  RF 
was  computed  as  a  function  of  glide  slope  deviation  error  and 
altitude  where  RC  was  computed  as  a  function  of  RF  and  localizer 
deviation.  These  position  measurements  were  blended  with  forward 
and  cross  velocities  from  the  INS  to  form  the  forward  and  lateral 
complementary  filters.  The  outputs  of  these  steady-state  Kalman 
filters  were  smoothed  estimates  of  forward  (RF)  and  cross  (Rfc) 
range  tc  the  touchdown  reference  point.  Hence,  in  this  mode, 
the  low  frequency  horizontal  guidance  of  the  aircraft  was  defined 
by  the  altitude  and  ILS  data;  the  INS  essentially  performed 
a  beam  smoothing  function  with  the  velocity  data.  After  localizer 
capture,  but  prior  to  glide  slope  capture,  rV  was  computed  from 
the  updated  INS  position  data  (latitude  and  longitude)  and  used 


A 

in  the  RC  calculation  to  intialize  the  forward  filter.  Likewise, 
prior  to  localizer  capture,  both  filters  were  initialized  from 
the  IMS.  In  addition,  appropriate  capture,  initialization, 
and  edit  by-pass  logic  was  provided  by  the  sensor  software  so 
that  the  mixer  would  v;ork  well  in  practice. 

c.  INS  Updater 


A 

The  INS  updater  simply  calibrated  the  INS  position  data  to  RF 
and  lCc  from  the  INS/ILS  mixer.  This  was  done  by  computing  approri- 
ate  offsets  to  be  added  to  the  INS  latitude  and  longitude  position 
data  from  rV  and  ift.  This  calculation  was  performed  anytime 
after  localizer  and/or  glide  slope  capture.  Consequently,  the 
INS  was  continually  being  updated  by  the  ILS  and  altitude  data 
whenever  possible.  Likewise,  the  ILS  simulation,  whenever  enabled, 
was  simply  a  reverse  calculation  of  localizer  and  glide  slope 
deviation  errors  using  the  updated  INS  position  data  and  altitude. 


Vertical  guidance  was  from  the  TIFS  altitude  and  altitude  rate  data 
and  a  radar  altimeter.  The  major  blocks  are  described  in  the  following. 

a.  Altitude  Selector 

The  altitude  selector  was  merely  logic  to  select  one  of  four 
A/D  channels  from  which  to  select  the  TIFS  altitude  data.  All 
four  A/D  channels  were  scaled  the  same  but  limited  in  range. 
This  scheme  allowed  for  a  fine  resolution  altitude  signal  with 
a  large  dynamic  range  using  twelve  bit  A/D  converters.  The 
resulting  altitude  signal  had  a  resolution  of  approximately 
+/-  one  foot  with  a  dynamic  range  of  0  to  15,250  feet. 

b.  Altitude  Complementary  Filter 

The  altitude  complementary  filter  was  implemented  to  perform 
the  same  function  as  the  INS  complementary  filter  discussed 
above;  that  is,  to  provide  high  resolution,  short-term,  altitude 
data  to  th»  display  software.  However,  because  the  altitude 
selector  worked  so  well,  this  filter  was  never  enabled  during 
the  CFPD  flight  evaluations. 

c.  Altitude  Blender 

The  altitude  blender  was  used  to  continually  calibrate  the  TIFS 
altitude  signal  whenever  the  radar  altimeter  data  were  flagged 
valid.  The  blender  was  a  steady-state  Kalman  filter  implemented 
to  estimate  a  bias  error  in  the  TIFS  altitude  data  using  the 
radar  altimeter.  The  blender  could  also  be  viewed  as  a  comple¬ 
mentary  filter,  which  had  the  important  property  that  high  frequency 
information  was  obtained  from  the  TIFS  altitude,  whereas  low 
frequency  information  was  extracted  from  the  radar  altimeter. 
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3. 3. 2. 1.3  High  Level  Sensor  Software  Structure 

The  sensor  software  consisted  of  the  main  routine  for  the  SENSOR 
task  (called  SENSOR),  seven  subroutines  and  four  completion  routines. 
The  completion  routines  were  called  from  the  operating  system  when  the 
LPAll-K  had  filled  (or  emptied)  a  data  buffer.  These  routines  ?ere  written 
to  manage  the  buffer  queue  set  up  for  the  LPA11-K. 

SENSOR  was  the  main,  but  relatively  small  routine  used  to  coordinate 
the  sensor  software.  During  program  initialization  or  stopping,  it  called 
the  SENINI  subroutine;  during  the  real-time  program  run  loop,  it  called 
SENUPD. 

The  SENINI  subroutine  initialized  the  sensor  software  and  initially 
configured  the  LPA11-K.  This  subroutine  did  not  start  the  LPA11-K  and 
was  invoked  only  at  system  initialization  and  system  stop.  It  was  invoked 
during  the  system  stop  sequence  to  shut  down  the  LPAll-K  and  display  data 
on  the  hard  copy  terminal.  In  particular,  this  subroutine  performed  the 
following  functions: 

a.  LPAll-K  shut  down  and  initialization 

b.  Initialization  of  data  and  control  indicators 

c.  Pre-computation  of  sensor  processing  constants 

d.  Pre-computation  of  runway  constants. 

The  SENOPT  subroutine  was  called  from  SENINI  during  program  initializa¬ 
tion  or  program  stop.  It  was  an  interactive,  user-friendly,  routine  that 
allowed  the  sensor  input  and  control  data  to  be  displayed  and  modified 
from  the  hard  copy  terminal  prior  to  using  the  data  during  sensor  intialization 
or  stop.  It  prompted  the  operator;  it  read  the  required  commands  and  data 
from  the  terminal;  and  it  modified  and/or  displayed  the  data  accordingly. 

The  SENDPD  routine  performed  the  main  real-time  processing  functions 
of  the  sensor  software.  This  routine  started  the  LPAll-K,  it  set  the  update 
rate  by  waiting  for  an  A/D  buffer  completion  and  it  managed  the  buffer 
queue.  In  addition,  all  computations  were  done  in  this  routine.  After 
all  sensor  computations  were  completed,  SENUPD  called  SENMOD;  SENKOD  performed 
all  the  real-time  sensor  software  mode  control  functions.  At  the  end  of 
SENUPD,  an  event  flag  was  set  to  synchronize  the  display  software. 


3. 3. 2. 1.4  Sensor  Software  Databases 

The  databases  were  grouped  as  to  whether  they  were  Global  or  Local. 
The  only  difference  between  the  two  was  that  the  Global  databases  were 
defined  to  be  accessible  to  the  Display  software  for  data  communication 
and  control,  whereas  the  Local  databases  were  only  available  to  the  Sensor 
software.  Each  database  consisted  of  one  or  more  labeled  common  blocks 
and  they  were  grouped  together  under  a  file  name  descriptive  of  how  they 
were  used  in  the  program  and  consistent  with  the  CFPD  Software  Specification 


3. 3, 2. 2  Timing 


The  update  rate  of  the  sensor  software  was  controlled  by  the  real-time 
clock  in  the  LPA11-K.  This  was  accomplished  by  initiating  the  sensor  software 
update  loop  at  the  end  of  each  A/D  data  input  sweep. 

All  synchronous  input/out  (I/O)  operations  in  the  LPA11-K  were  driven 
and  synchronized  by  the  real-time  clock  overflow  rate.  This  overflow  rate 
was  set  by  the  sensor  software  and  it  applied  to  all  active  I/O  requests. 
Control  parameters  were  available  to  allow  several  concurrent  requests 
to  specify  different  sampling  rates  or  sampling  patterns,  but  the  sampling 
rates  had  to  be  a  multiple  of  the  real-time  clock  overflow  rate. 

The  sampling  patterns  set-up  for  the  synchronous  I/O  date  transfers 
for  the  CFPD  system  included  the  analog-to-digital  (AD)  input  sweep;  the 
synchro-to-digital  output  (SDO)  control  sweep;  the  synchro-to-digital  input 
(SDI)  sweep;  and  the  discrete  word  input  sweep  (DIS).  The  SDI  and  D1S 
were  "externally"  triggered  input  sweeps  which  were  controlled  by  the  SDO 
output  sweep.  This  was  set  up  in  the  Calspan  interface  design  so  that 
a  particular  synchro-to-digital  input  channel  or  a  discrete  word  input 
could  be  activated  and  its  input  synchronized  to  the  other  I/O  under  program 
control. 


The  AD  sweep  pattern  was  set  up  to  convert  and  input  forty  consecutive 
A/D  channels  (one  per  each  clock  overflow),  wait  460  clock  overflows,  and 
then  repeat.  Since  the  sensor  software  was  activated  after  the  forty 
channels  of  the  A/D  data  are  inputted  to  memory  by  the  LPA11-K,  the  real-time 
loop  time  duration  was  equivalent  to  500  clock  overflows.  Consequently, 
for  a  twenty  Hz  update  rate  the  clock  was  set  to  overflow  every  one  hundred 
microseconds,  whereas  for  the  fifteen  HZ  update  rate  the  overflow  was 
set  for  every  133  microseconds.  An  update  rate  of  fifteen  Hz  was  used 
for  the  CFPD  flight  evaluations. 

The  SDO  sweep  was  set  up  to  output  data  every  ten  clock  overflows. 
However,  only  five  of  these  outputs  were  coded  to  activate  a  SDI  and  DIS 
each  update  cycle  and  the  first  one  started  fifteen  clock  overflows  ahead 
of  the  first  A/D  channel  to  be  converted.  This  insured  that  all  data  input 
to  the  computer  would  be  fresh  (most  recent)  at  the  start  of  the  real-time 
loop.  This  also  insured  that  the  maximum  aggregate  instantaneous  throughput 
rate  for  all  active  requests  on  the  LPA11-K,  when  in  the  multirequest  mode, 
would  not  exceed  15K  Hz. 

The  sensor  software  timing  results  were  obtained  with  the  PPD-11/44 
computer  system  operating  with  the  sensor  test  software.  The  sensor  software 
took  approximately  6-8  milliseconds  to  complete  depending  upon  the  sensor 
mode  of  operation.  The  Flight  Mode  was  close  to  six  milliseconds,  whereas 
the  Ground  Simulation  Mode  was  around  eight  milliseconds.  It  is  estimated 
that  it  took  approximately  two  milliseconds  of  system  overhead  time  to 
service  the  buffer  queue  of  each  LPA11-K  sweep.  The  remainder  of  the  loop 
time  was  used  by  the  display  software  and  other  system  overhead. 

The  other  sensor  software  system  overhead  came  from  managing  the 


I/O  buffer  queues  for  the  SDO,  SDI  and  DIS  sweeps  discussed  above  and  the 
serial-to-parallel  input  (SPl)  from  the  INS.  The  SPI  was  an  "externally" 
triggered  "asynchronous"  digital  input  sweep  from  the  INS  which  was  inputted 
at  a  24.16  Hz  rate. 

It  was  estimated  that  it  took  two  milliseconds  of  system  overhead 
time  to  service  each  I/O  buffer  queue.  Since  the  SPI  was  an  asychronous 
input  to  the  computer,  its  buffer  queue  had  to  be  serviced  each  time  an 
input  was  received,  and  that  could  be  as  high  as  two  per  sensor  software 
update  time.  To  reduce  the  I/O  overhead  time,  the  SDO,  SDI  and  DIS  sweeps 
were  implemented  with  long  buffers,  interleaved  in  such  a  fashion  that 
only  one  of  their  buffer  I/O  queues  had  to  be  managed  for  every  six  updates 
of  the  sensor  software.  This  scheme  reduced  significantly  the  amount  of 
overhead  time  required  to  service  the  I/O  buffer  queues. 

In  the  Flight  Mode,  the  sensor  software  would  use  a  minimum  of  ten 
milliseconds  to  a  maximum  of  fourteen  milliseconds  of  time  for  each  update 
cycle.  At  a  fifteen  Hz  update  rate,  52.5  -  56.5  milliseconds  would  remain 
available  for  the  display  software. 

With  the  final  version  of  the  overall  CFPD  software,  a  fifteen  Pertz 
update  rate  was  achieved  with  either  the  CFPD  display  or  the  F-18  symbology 
display.  A  twenty  Hertz  update  rate  could  be  maintained  with  the  CFPD 
display,  but  it  was  marginal;  twenty  Hertz  could  not  be  achieved  with  the 
F-18  display.  Consequently,  all  flight  test  evaluations  were  conducted 
with  a  fifteen  Hertz  update  rate. 


3.3.3  Evans  &  Sutherland's  Contribution 

The  Evans  &  Sutherland  PS-300  display  system  used  in  this  project 
normally  accepts  command  and  data  in  the  form  of  a  high  level,  ASCII  text 
stream  with  an  effective  bandwidth  of  about  1200  baud.  (The  interface 
hardware  is  capable  of  56K  baud  transmission,  but  the  standard  PS- 300  firmware 
is  only  able  to  process  input  commands  at  about  1200  baud.)  CFPD  requirements 
were  more  on  the  order  of  30K  baud.  Consequently,  Evans  &  Sutherland  developed 
firmware  customized  for  the  CFPD  and  symbology  displays  which  would  support 
binary  data  transmission  over  the  standard  56K  baud  interface.  This  firmware 
was  incorporated  into  the  control  program  loaded  into  the  PS-300  during 
power-up . 


3.4  System  Installation 

Installation  in  the  NC-131H  comes  under  the  Air  Force  system  of 
documentation  and  approval  application  to  Class  II  Modifications,  which 
are  temporary  installation  for  research,  development,  test,  and  evaluation 
purposes.  The  CFPD  System,  with  the  exception  of  the  inertial  navigation 
system  and  the  HUD,  was  comprised  of  standard  commercial  equipment.  To 
power  the  equipment,  the  existing  1500VA  sixty  Hz  rotary  inverter  was 
permanently  replaced  with  two  3500VA  sixty  Kz  static  frequency  converters. 
To  ensure  proper  functioning  in  a  flight  environment,  the  equipment  was 


ruggedized  and  then  subjected  to  vibration  testing  at  Calspan.  The  system 
equipment  successfully  passed  the  vibration  test,  was  certified  safe  for 
flight  in  the  CFPD  Class  II  Modification  Part  II,  and  was  installed  in 
the  TIFS  by  Calspan  personnel. 


3.4.1  Frequency  Converter  Installation 

The  majority  of  equipment  installed  in  TIFS  for  the  CFPD  program 
was  standard  office-type  equipment  not  capable  of  operating  on  four  hundred 
Hz  line  power.  To  accommodate  this  equipment,  the  existing  1500VA  sixty 
Kz  rotary  inverter  was  permanently  replaced  with  two  3500VA  sixty  Hz  static 
frequency  converters.  The  converters  could  not  be  paralleled,  therefore, 
a  two-bus  distribution  network  was  installed  where  either  converter  could 
supply  either  one  or  both  buses.  Both  converters  cannot  be  tied  to  the 
same  output  bus. 

Two  line  filters  were  installed—one  to  filter  the  PS-300  power 
and  the  other  to  filter  the  PDP-11/ 44,  I/O  chassis  and  DEC  writer  power. 


3.4.2  Vibration  Testing 

All  CFPD  equipment,  except  for  the  inertial  navigation  system  and 
the  HUD  which  are  designed  for  airborne  use,  were  exposed  to  vibration 
typical  of  the  TIFS.  A  simple  test  was  devised  using  a  sinusoidal  shaker 
input  at  frequencies  and  amplitudes  observed  on  flight  records  in  the  cockpit 
and  cabin  areas.  All  equipment  had  been  inspected  and  hardened  by  Calspan 
where  needed.  Each  unit  was  under  power '  during  its  test.  All  equipment 
passed  the  test  without  incident. 


3.4.3  Hardware  Mounting  Location 

The  mounting  locations  for  the  major  CFPD  equipment  items  are  identified 
in  Figure  3-2.  Except  for  the  graphics  processor  and  the  video  recorder 
and  power  supply,  all  CFPD  equipment  was  hand  mounted  in  the  TIFS  aircraft. 
Equipment  locations,  except  cockpit  displays,  were  selected  for  aircraft 
center  of  gravity  considerations,  ease  of  operation  by  crew  members  and 
accessibility  for  maintenance.  The  cabinets  designated  "CFPD  Computer 
System"  in  Figure  3-2  are  detailed  in  Figure  3-3.  Photographs  of  the  installa¬ 
tions  are  presented  in  Appendix  F. 


3.4.4  Evaluation  Cockpit  Configuration 

All  standard  instrumentation  was  removed  from  the  evaluation  pilot 
(left  seat)  instrument  panel.  A  XYTRON  display  was  installed  in  the  HSI 
position  and  a  Head-Up-Display  (HUD)  tray  mounted  above  it.  The  tray 
was  oriented  for  proper  HUD  viewing  angle  and  would  accept  the  Hughes  "AIDS" 
HUD  or  a  second  XYTRON  display.  An  adaptor  was  fabricated  and  secured 
to  the  removable  XYTRON  CRT  display  to  provide  the  desired  viewing  position 
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when  the  XYTROhi  display  was  installed  m  the  HUD  tray. 

The  window  areas  adjacent  to  the  pilot  seats  were  sealed  with  an 
opaque  material  and  forward  view  was  obscured  by  a  translucent  cloth  hung 
from  the  overhead  beam  to  forward  of  the  HUD  combiner  glass  to  simulate 
IFR  flight.  For  VFR  flight  conditions,  the  translucent  cloth  was  removed 
from  the  Velcro  attachments. 

To  prevent  reflections  from  the  CFPD  installations  onto  the  forward 
windscreen,  a  black  cloth  was  installed  forward  of  the  instrument  panel. 
A  side  view  of  the  general  layout  of  the  evaluation  cockpit  is  shown  in 
Figure  3-4. 


4.0  FLIGHT  TEST 


The  overall  objective  for  Phase  II  was  to  conduct  flight  tests  of 
the  Command  Flight  Path  Display  system  in  order  to  validate  the  display 
concept.  Twenty  hours  of  flight  time  were  allocated  for  the  validation. 
The  target  date  for  the  first  flight,  established  at  the  Phase  I  kick  off 
meeting,  was  February  1,  1983.  All  milestones  were  established  to  accomplish 
this  goal  on  time.  A  two  month  window  for  completion  of  the  twenty  hours 
of  flight  test  was  available  but  submission  of  flight  data  was  promised 
to  NAVAIR  by  the  end  of  February. 

The  installation  of  the  CFPD  system  was  completed  in  mid  January. 
Ground  simulation  commenced  on  January  27,  1983,  following  a  short  review 
meeting.  The  only  open  action  item  at  the  meeting  was  Air  Force  approval 
of  the  modifications  to  TIFS  which  was  required  prior  to  the  first  flight. 

Verbal  approval  of  the  Class  II  Part  II  modification  was  finally 
received  on  February  8,  1983.  The  first  flight  was  scheduled  for  the  following 
day  and  was  successfully  executed.  The  second  flight  was  flown  on  February 
10,  1983.  Data  from  the  first  two  flights  were  prepared  and  provided  to 
NAVAIR  on  February  28,  1983.  No  further  flights  were  flown  until  March 
3,  1983,  due  to  pilot  unavailability.  Two  pilots  from  the  Naval  Air  Test 
Center  and  two  from  the  Naval  Air  Development  Center  participated  in  the 
flight  test  during  March. 

The  flight  test  window  was  extended  into  April  to  allow  VADM  E.R. 
Seymour,  Commander,  Naval  Air  Systems  Command,  to  participate.  VADM  Seymour's 
visit  had  been  postponed  from  February  9,  1983,  when  modification  approval 
delay  prevented  system  checkout  in  flight  prior  to  his  arrival.  CAPT  R.D. 
Friichtenicht ,  NAVAIR  03,  accompanied  VADM  Seymour  and  also  flew  the  flight 
test  patterns.  Two  additional  flights  were  flown  on  the  CFPD  system  by 
U.S.  Naval  Test  Pilot  School  pilots  from  Patuxent  River.  These  pilots 
were  not  part  of  the  flight  test,  but  flew  the  system  for  TPS  syllabus 
requirements  when  the  X-22A  aircraft  at  Calspan  could  not  be  flown. 

Little  cooperation  was  expected  from  the  weather  in  Buffalo,  New 
York,  during  the  flight  test.  Fortunately  it  was  a  mild  winter  and  only 
one  scheduled  flight  was  cancelled  due  to  meteorological  conditions.  Snow, 
high  winds,  and  turbulence  were  all  encountered  without  adverse  effect 
on  the  CFPD  display. 


4.1  Flight  Test  Plan 

?l;t  development  of  the  flight  test  plan  was  based  on  many  critical 
factors.  Criteria  used  were: 

a.  The  Program  Objectives 

b.  Total  flight  time  available  -  20  hours 

c.  Maximum  time  for  a  single  flight  -  2  hours 

d.  Maximum  video  tape  recording  time  -  30  minutes 

e.  Evaluation  of  F-18  symbology  relative  to  the  CFPD 


f.  Evaluation  of  both  displays  on  CF.Ts  under  simulated  zero- 
zero  conditions  and  on  the  Hughes  AIDS  HUD 

g.  Actual  coupled  ILS  approaches  under  simulated  zero-zero 
conditions  on  the  VSI  and  with  the  AIDS  HUT 

h.  Time  to  reach  the  flight  test  area  and  time  to  return 
to  base 

i.  Indoctrination  of  the  evaluation  pilots 

j.  Calspan  safety  requirements. 

A  flight  test  pattern  was  developed  that  consisted  of  a  modified 
instrument  pattern.  (Figure  2-6)  It  was  composed  of  interrelated  maneuvers 
and  performances  basic  to  normal  IFR  flight.  The  initial  climbout  to  1000 
feet  and  the  approach  portion  from  completion  of  the  first  45  degree  turn 
to  touchdown  were  flown  on  indicated  airspeed  (IAS).  The  remainder  of 
the  flight  plan  was  flown  on  groundspeed.  The  following  breakdown  of  the 
flight  test  pattern  was  provided  to  each  pilot  in  the  briefing  guide. 


Leg  1 

1.  Leg  1  begins  at  the  rotation  point. 

2.  Maintain  runway  heading,  climbout  at  3  degrees  flight  path  angle 
and  170  kts  IAS  until  reaching  1000  feet. 

3.  Raise  gear  and  flaps  as  required. 

4.  Upon  reaching  1000  feet  reduce  flight  path  angle  to  1.7  degrees 
and  continue  to  climb  at  500  fpm  and  185  kts  groundspeed. 

Lg&  l 

1.  At  waypoint  1  commence  a  90  degree  right  turn  continuing  to 
climb  and  leveling  off  at  2000  feet,  185  kts  groundspeed. 

2.  Maintain  heading,  altitude,  and  groundspeed. 

3.  At  11.4  DME  start  a  level  speed  change  to  215  kts. 

4.  At  8.2  DME  start  a  level  speed  change  to  185  kts. 

5.  At  4.2  DME  start  a  level  speed  change  to  215  kts. 

Leg  3 

1.  At  waypoint  2  commence  a  90  degree  right  turn,  maintain  2000 
feet  and  215  kts  groundspeed. 

2.  After  completion  of  the  turn,  maintain  heading,  altitude,  and 
groundspeed  until  reaching  waypoint  3. 

Leg  4 

1.  At  waypoint  3  commence  a  90  degree  right  turn. 

2.  After  completion  of  turn  commence  a  185  kts  climb  to  3000  feet. 
Upon  reaching  3000  feet,  level  off  and  increase  groundspeed 

to  215  kts. 

3.  Maintain  heading,  altitude,  and  groundspeed  until  reaching 
waypoint  4. 
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1.  At  waypoint  4  commence  180  degree  left  turn,  maintaining  3000 
feet,  215  kts. 

2.  At  .7  DME  commence  a  50C  fpm  descent  to  1300  feet. 


Leg  6 


1.  At  waypoint  5  commence  a  90  degree  right  turn  at  215  kts,  continuing 
to  descend  at  500  fpm  to  1300  feet. 

2.  After  completion  of  the  turn,  maintain  heading,  groundspeed, 
and  descent. 


teg  7 


1.  At  waypoint  6  commence  a  90  degree  turn  at  215  kts,  continuing 
to  descend  at  500  fpm  to  1300  feet. 

2.  After  completion  of  turn,  maintain  heading  and  groundspeed. 

Level  off  at  1300  feet. 

3.  At  6.7  DME  start  a  level  speed  change  to  185  kts. 

4.  Maintain  heading,  altitude  and  groundpseed  until  reaching 
waypoint  7. 


Leg  8 


1.  At  waypoint  7  commence  a  45  degree  right  turn. 

2.  At  completion  of  turn  commence  level  speed  change  to  150  kts 
IAS.  Maintain  heading  and  altitude.  The  ILS  steering  display 
will  appear.  (E.g.  elevation  and  azimuth  deviation  nee'dles 
referenced  to  the  velocity  indicator.) 

3.  Perform  the  landing  checklist  as  required. 

4.  Waypoint  9  is  the  touchdown  point. 


This  pattern  served  as  the  basis  for  the  flight  test  plan.  A  schedule 
was  prepared  to  cover  the  twenty  hours  of  flight  time  available.  Pilot 
availability  necessitated  changes  to  the  original  schedule  and  resulted 
in  the  actual  schedule  shown  in  Figure  4-1. 


Each  pilot  selected  to  participate  in  the  flight  test  was  briefed 
the  night  before  his  first  flight.  He  was  asked  to  read  a  CFPD  briefing 
guide  which  explained  the  program  objectives,  the  concept  definition, 
and  the  flight  test  plan.  The  following  day  the  pilot  was  asked  to  fly 
the  pattern  in  the  ground  simulation,  first  on  the  symbology  and  then  on 
the  CFPD. 


When  the  simulation  was  complete,  the  aircraft  was  disconnected 
from  the  ground  computers  and  prepared  for  flight.  The  pilot  was  briefed 
by  the  safety  pilots  on  weather  and  safety.  Following  the  brief,  the  aircraft 
was  manned  and  the  safety  pilots  departed  Buffalo.  When  in  position,  and 
with  the  display  ready,  control  of  the  aircraft  was  transferred  to  the 
pilot  in  the  evaluation  cockpit.  The  pilot  flew  the  pattern,  once  on  the 
symbology  display  and  again  on  the  CFPD  display.  At  the  completion  of 


the  pattern  work  the  aircraft  was  repositioned  by  the  safety  pilots  to 
intercept  the  ILS  approach  Runway  28  at  Niagara.  Control  of  the  aircraft 
was  again  turned  over  to  the  pilot  in  the  evaluation  cockpit  for  one  approach 
using  the  symbology  display  and  one  approach  on  the  CFPD  display. 

The  F-18  symbology  was  modified  slightly  to  reflect  TIFS  performance 
parameters.  Ground  track  up,  heading  up,  and  North  up  formats  were  available. 
The  following  details  the  differences  from  the  standard  F-18  symbology. 

a.  F-18  uses  two  different  character  sizes  within  the  altitude 
readout  box  on  the  VSD.  Our  version  used  one  size. 

b.  Characters  on  the  compass  rose  of  the  F-18  HSD  always 
remain  upright,  ours  rotated  with  the  compass  rose. 

c.  The  following  were  eliminated  from  the  basic  flight  data: 

1)  Angle  of  Attack  Readout 

2)  Mach  Number 

3)  Aircraft  G 

A)  Peak  Aircraft  G 
5)  Ghost  Velocity  Vector 

d.  No  Advisory  Data  Symbology  was  provided 

e.  No  Steering  (Waypoint  Direct)  Symbology  was  provided 

f .  Steering  (TCN/WYPT  Course)  Symbology  was  provided  with  the  following 
differences : 

1)  Waypoints  were  predetermined  and  provided  as  shown  in  Figure 
2-6  without  station  identifier. 

2)  The  CD  I  on  the  F-18  VSD  shows  angular  deviation  from  course 
line,  the  modified  version  showed  lateral  displacement. 
If  the  needle  is  on  the  first  (second)  dot,  ownship  is  2000 
feet  (4000  feet)  off  of  course  centerline.  Standard  F-18 
would  have  been  4  degrees  and  8  degrees  respectively. 

g.  The  altitude  presented  in  the  box  was  barometric  altitude. 
The  runway  was  represented  as  O'  Mean  Sea  Level  (MSL). 

h.  The  Waterline  symbol  was  always  provided  for  pitch  attitude 
reference.  It  was  moved  to  correspond  to  TIFS  KUD  location 
or  removed  entirely  when  desired. 

i.  The  landing  display  was  presented  on  the  approach  leg  only. 

j.  The  AOA  bracket  was  set  up  to  correspond  to  TIFS  parameters. 

The  center  of  the  bracket  represented  the  optimum  approach 
angle  of  attack  (3.6  degrees  true).  The  length  of  the  bracket 
represents  about  plus  or  minus  two  degrees.  No  backup  approach 
indexers  were  provided. 

4.2  Ground  Simulation 

Ground  simulation  began  on  January  27,  1983.  The  simulation  utilized 
the  TIFS  aircraft  which  was  configured  for  control  from  the  left  hand  evalua¬ 
tion  cockpit  seat.  The  left  seat  was  arranged  with  left-hand  throttles, 
a  center  stick  and  standard  rudder  pedals.  Ground  computers  capable  of 
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reproducing  the  TIFS  equations  of  motions  were  connected  to  the  aircraft. 

Initial  simulation  work  was  planned  for  display  adjustments  as  well 
as  software  exercise.  Immediate  problems  were  encountered  with  aircraft 
control  stability.  A  basic  TIFS  feel  system  was  requested  from  Calspan. 
After  several  attempts,  agreement  was  reached  among  the  Calspan  pilots 
that  the  feel  system  was  configured  for  the  basic  TIFS.  Final  adjustments 
to  the  force  feel  system,  gearings,  trim  rates,  aileron  to  rudder  interconnect, 
and  Dutch  roll  damping  were  made  on  the  first  flight  but  no  further  changes 
were  made  for  the  duration  of  the  flight  test  program.  Actual  values  for 
the  feel  system  gains  and  control  system  configuration  of  TIFS,  used  during 
the  flight  test,  can  be  found  in  Calspan  Report  No.  6645-F-12. 

Subtle  adjustments  to  the  CFPD  display  were  made  during  the  first 
week  of  ground  simulation.  These  included  size,  position,  and  travel  limits 
of  the  velocity  indicator,  coupling  and  uncoupling  of  the  velocity  indicator 
to  the  command  position,  horizon  gradient,  number  of  earth  plane  lines, 
amount  of  pattern  visible,  brightness  contrast,  dimension  and  spacing  of 
plates,  dimensions  of  runway,  blending  of  plates  and  runway,  and  steepness 
of  pattern  turns.  In  most  cases  adjustments  were  made  within  a  matter 
of  seconds  from  the  CFPD  engineer's  station.  Software  tapes  with  permanent 
modifications  were  prepared  at  Intermetrics  and  provided  as  required  to 
support  the  simulation  and  flight  test.  Messrs.  Steve  Shelley,  Neil  Akiyama, 
and  Paul  Slonaker  provided  this  support  by  rotating  between  Boston,  Massachu¬ 
setts,  and  Buffalo,  New  York.  At  least  one  of  them  was  on  site  at  Calspan 
as  CFPD  engineer  for  the  entire  ground  simulation  and  on  board  TIFS  for 
each  test  flight. 

Use  of  the  ground  simulation  continued  for  the  duration  of  the  flight 
test.  Each  pilot  selected  for  participation  flew  the  test  flight  pattern 
on  the  symbology  and  on  the  CFPD  prior  to  actual  flight. 

Demonstrations  of  the  CFPD  for  program  participants  were  run  on 
a  non  interference  basis.  Non  pilots  were  able  to  fly  the  CFPD,  without 
training.  This  provided  additional  proof  that  the  display  was  truly  integrated 
and  had  the  necessary  visual  cues. 

Approximately  ninety-one  hours  of  simulation  time  were  accumulated 
during  the  course  of  the  program. 

4.3  Flight  Test 

The  procedure  to  initiate  the  flight  test  was  for  the  safety  pilots 
to  depart  Buffalo,  climb  to  altitude,  and  position  the  aircraft  for  the 
start  of  the  flight  test.  The  starting  point  depended  on  whether  the  evalua¬ 
tion  pilot  preferred  to  do  the  approaches  at  Niagara  or  the  test  pattern 
work  first.  He  was  given  his  choice.  In  addition  he  was  given  the  option 
of  which  display  format  to  start  with,  either  the  symbology  or  the  Command 
Flight  Path. 

When  the  safety  pilot  was  approaching  the  initial  point,  the  CFPD 


engineer  would  bring  up  the  display  format  to  be  flown  and  the  evaluation 
pilot  would  engage  the  feel  system  in  the  evaluation  cockpit.  When  all 
were  ready,  control  of  the  aircraft  was  passed  to  the  evaluation  cockpit. 
Responsibility  for  visual  traffic  separat ion  and  radio  communications  remained 
with  the  safety  pilots. 

The  evaluation  pilot  would  execute  his  take-off  in  "virtual"  airspace 
for  the  flight  test  pattern.  The  pattern  covered  approximately  27  square 
miles  with  a  perimeter  of  roughly  78.5  miles.  Approximately  25  minutes 
were  required  to  cover  the  course  which  terminated  with  an  approach  to 
the  same  position  that  the  pattern  commenced. 

When  the  first  pattern  was  completed  the  safety  pilot  would  take 
control  of  the  aircraft  and  turn  to  reposition  at  the  starting  point  allowing 
sufficient  time  for  the  CFPD  engineer  to  bring  up  the  display  format  for 
the  second  pattern  and  the  evaluation  pilot  to  engage  the  evaluation  cockpit 
feel  system  again.  The  same  procedure  for  transferring  control  of  the 
aircraft  would  be  followed  once  the  aircraft  was  in  position  and  all  were 
ready . 


The  evaluation  pilot  would  take  control  of  the  aircraft  for  the 
approach  at  Niagara  after  the  safety  pilot  had  engaged  the  ILS  outside 
of  the  outer  marker.  He  would  fly  the  approach  until  control  was  taken 
back  by  the  safety  pilot,  usually  at  an  altitude  of  approximately  150  feet. 
The  safety  pilots  would  execute  a  missed  approach  and  reposition  the  aircraft 
outside  the  outer  marker  for  another  approach. 

A  total  of  nine  pilots  participated  in  the  flight  test  flying  over 
twenty  hours.  Two  additional  pilots  from  the  U.S.  Naval  Test  Pilot  School 
(TPS)  flew  the  CFPD  system  for  over  three  hours  to  complete  TPS  syllabus 
requirements  when  the  X-22A  aircraft  at  Calspan  could  not  be  flown. 

On  every  flight  a  second  pilot  was  in  the  right  seat  of  the  evaluation 
cockpit.  The  second  pilot  provided  verbal  cues  to  the  evaluation  pilot 
during  the  test  pattern.  Comments  made  while  on  the  CFPD  were  limited 
as  compared  to  a  constant  stream  of  prompting  while  on  the  symbology  display. 
A  much  greater  magnitude  of  departures  would  have  been  experienced  on  the 
symbology  patterns  if  the  evaluation  pilot  had  relied  strictly  on  the  test 
pattern  and  not  received  verbal  inputs  from  the  second  seat. 

The  last  flight  utilizing  the  CFPD  system  was  flown  on  April  20, 
1983.  The  system  equipment  was  removed  and  shipped  in  accordance  with 
NADC  instructions. 


4. A  Data  Reduction 

The  Data  Reduction  for  CFPD  was  performed  at  Intermetrics,  Inc. 
on  the  data  recorded  during  each  flight  by  the  Recorder  task.  Whenever 
possible,  automated  mechanisms  were  developed  to  facilitate  the  process 
and  reduce  the  human  interface.  The  reduction  occurred  in  several  phases, 
each  identified  by  a  specific  function. 
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Since  the  Recorder  task  performed  no  processing  on  the  recorded 
flight  data,  the  first  phase  involved  identifying  and  separating  the  data 
sets  associated  with  the  various  flight  exercises  (for  each  flight): 

a.  Flying  the  command  path  using  the  CFPD 

b.  Flying  the  command  path  using  the  symbology  display 

c.  Flying  the  approach  to  Niagara  using  the  CFPD 

d.  Flying  the  approach  to  Niagara  using  the  symbology  display 

Throughout  the  flights,  messages  were  generated  automatically  by  the  Operator 
task  which  signalled  certain  events  (e.g.,  system  initialization);  these 
messages  along  with  comments  entered  by  the  operator  were  sent  to  the 
Recorder  task  and  formed  a  chronology  which  helped  during  this  phase. 


4.4.2  Phase  II 

The  next  phase  involved  obtaining  reference  and/or  timing  information 
used  to  coordinate  and  identify  data  within  each  data  set.  The  information 
included  three-dimensional  position  data  (actual,  projected  onto  the  command 
path  and  command),  flight  path  referenced  position  data  (distance  from 
take-off,  "route"  number)  and  deviations  (altitude  and  lateral).  Also 
during  this  phase,  extraneous  information  (e.g.,  text  messages)  interspersed 
during  the  flights  by  the  operator  are  removed.  The  end  result  is  a  data 
file  containing  all  the  information  needed  to  perform  the  subsequent  data 
analysis.  The  kinds  of  data  recorded  on  the  flight  tapes  and  the  data 
determined  during  this  phase  both  evolved  as  a  result  of  work  on  CFPD. 
During  the  initial  flight  tests,  data  were  collected  and  reduced;  from 
the  preliminary  plots,  it  was  determined  what  data  were  needed  (in  addition 
to  data  being  recorded)  and  what  kinds  of  information  were  to  be  presented. 


4.4.3  Phase  III 

The  data  were  then  analyzed  to  determine  various  statistical  parameters, 
some  of  which  were  necessary  for  the  plotting  phase.  These  include  the 
minimum,  maximum,  and  average  values  of  altitude  deviation  and  lateral 
deviation.  The  statistical  data  also  evolved  to  include  such  data  as 
percent-time  within  certain  deviations  (e.g.,  within  +/-  73  feet  of  the 
the  command  path). 


4.4.4  Phase  IV 

Appropriate  plotting  data  were  extracted  for  each  plot  depending 
on  the  desired  parameters;  for  example,  altitude  deviation  versus  distance 
aiong  the  command  path.  Th?se  data  were  then  formatted  so  as  to  be  compatible 
with  the  plotting  package  used  during  Phase  V. 

During  the  writing  of  this  final  report,  it  was  determined  that 


additional  plots  of  a  more  integrated  format  were  required  as  examples. 
These  plots  were  generated  by  hand  based  on  data  generated  during  this 
phase. 


4.4.5  Phase  V 

Finally,  the  Z CHART  Plotting  Package  was  used  to  actually  generate 
the  various  plots,  utilizing  the  data  generated  during  Phase  IV  and  the 
scaling  parameters  determined  during  Phase  III.  Each  CFPD  flight  was  repre¬ 
sented  by  a  set  of  data  plots  which  presented  various  areas  of  interest 
as  specified  by  the  goals  of  the  project.  The  plots  included  (for  each 
pilot) : 

1.  Altitude  plots  using  the  CFPD 

2.  Lateral  deviation  (from  the  Commanded  Position)  plots  using 
the  CFPD 

3.  Velocity  plots  using  the  CFPD 

4.  Altitude  plots  using  the  symbology  display 

5.  Lateral  deviation  (from  the  Commanded  Position)  plots  using 
the  symbology  display 

6.  Velocity  plots  using  the  symbology  display 
These  plots  are  included  in  Appendix  D  of  this  report. 


5.0  DATA  REDUCTION  RESULTS 


In  viewing  the  CFPD  and  Symbology  plots  resulting  from  the  data 
reduction,  it  was  noted  that  flight  plan  departures  can  be  categorized 
into  three  error  types--Ant icipation  and  Reaction,  Pilot  Workload,  and 
Mon-linear  Course  Tracking.  These  generic  categories  are  discussed  in 
the  following  sections.  Examples  of  these  categories  are  derived  from 
the  plots  contained  in  Appendix  F  and  included  for  illustrative  purposes. 
While  they  are  not  shown  in  the  same  format  as  the  standard  flight  test 
plots,  the  examples  in  the  following  sections  do  represent  actual  flight 
test  events  and  data.  Plots  containing  more  than  one  test  case  (i.e., 
both  CFPD  and  Symbology)  depict  consecutively  flown  test  cases  by  the  same 
pilot  during  the  same  flight.  On  some  of  the  examples,  the  altitude  data 
were  deleted  as  it  did  not  pertain  to  the  concept  being  discussed. 


5.0.1  Description  of  Example  Plots 

The  plot  figures  included  as  examples  in  the  following  sections 
were  designed  to  depict  lateral,  vertical,  and  longitudinal  errors  along 
a  common  axis  (distance  along  the  flight  path).  Lateral  and  vertical  depart¬ 
ures  are  shown  as  line  graphs  indicating  the  distance  left  or  right  of 
the  flight  path  for  lateral  errors  and  the  actual  altitude  flown  for  vertical 
errors. 


Note 

While  flying  the  CFPD  flight  tests,  pilots  tended  to 
fly  above  the  command  flight  path  at  some  personally  comfortable 
height.  This  offset  was  not  removed  from  the  altitude  plots 
in  the  examples. 

Longitudinal  errors  are  depicted  by  taking  "snapshots"  of  the  flight  data 
and  plotting  where  the  aircraft  was  positioned  relative  to  the  start  of 
the  flight  plan  and  the  commanded  position.  The  distance  between  the  Command 
Position  and  the  CFPD/ Symbology  Position  markers  for  each  snapshot  indicate 
how  far  ahead  or  behind  flight  plan  the  pilot  is  at  that  particular  moment. 


5.0.2  Anticipation  and  Reaction 

Anticipation  and  Reaction  type  errors  relate  to  the  inability  of 
the  pilot  to  anticipate  maneuvers  and  control  corrections  and  to  react 
in  a  timely  and  correct  manner  to  indicated  deviations.  The  most  graphic 
examples  of  these  types  of  errors  occurred  while  intercepting  and  tracking 
a  given  course  line  or  setting  up  and  executing  an  ILS  approach.  When 
flying  the  Symbology  format,  pilots  typically  experienced  difficulty  in 
anticipating  the  correct  time  to  "roll-out"  of  a  turn  and  the  correct  heading 
to  hold.  The  general  tendency  is  to  "bracket"  the  desired  course  line 
or  glide  slope,  eventually  converging  on  the  correct  control  inputs  to 
maintain  course.  Lateral  deviation  plots  showing  these  cases  can  be  easily 
recognized  as  they  exhibit  a  damped  oscillation  towards  zero  error.  However, 


when  flying  the  CFPD  format,  the  same  pilots  never  really  "lost"  the  command 
information.  (The  single  exception  is  discussed  in  the  next  paragraph.) 
In  fact,  they  never  deviated  far  enough  to  demonstrate  any  bracketing-like 
tendency.  Figure  5-1  demonstrates  this. 

During  one  flight,  a  pilot  flying  the  CFPD  format  intentionally 
departed  from  the  command  flight  path  to  investigate  how  easy  it  is  to 
re-intercept  the  commanded  course.  Figure  5-2  shows  that  the  pilot  did 
not  appear  to  have  to  "search"  for  the  correct  control  inputs  to  intercept 
and  maintain  course.  The  pilots  "convergence"  on  the  correct  control  inputs 
was  extremely  rapid  when  compared  to  the  performances  using  the  Symbology 
format. 


Another  very  common  flight  plan  deviation  involved  the  interception 
of  the  Localizer  and/or  Glide  Slope  during  an  ILS  approach.  (Figure  5-3) 
A  large  majority  of  the  pilots  exhibited  an  overshoot  of  the  localizer 
course.  Similar  difficulties  were  not  experienced  by  the  pilots  flying 
CFPD.  Whether  these  difficulties  could  be  attributed  to  the  change  in 
format  (Cruise  to  Approach)  with  its  attendant  change  in  sensitivities 
or  the  change  in  command  type  (fly  at  a  given  altitude  digital  value  to 
follow  the  glide  slope  needle)  was  not  determined. 

Note 

Data  for  longitudinal  errors  (the  position  plots)  were 
not  included  as  the  velocity  being  commanded  during  approach 
was  Indicated  Airspeed,  not  Ground  Speed.  In  other  words, 
there  was  no  pre-determined  geographic  command  position  for 
the  aircraft;  "how  goes  it"  was  instantaneous,  not  cumulative. 


5.0.3  Pilot  Workload 

It  is  widely  accepted  that  operator  performance  of  a  given  task 
is  directly  related  to  the  operator-perceived  workload.  This  workload 
is  not  only  a  function  of  the  required  control  inputs,  but  is  dependent 
on  the  quality  (accuracy,  timeliness,  completeness,  presentation  medium, 
etc.)  of  the  information  presented  to  the  operator.  These  human  factors 
concepts  are  applicable  to  the  piloting  task  incorporated  into  the  CFPD 
flight  tests.  While  not  measured  quantitatively,  evaluation  pilot  assessments 
of  their  perceived  workload  was  collected  during  the  debriefing  sessions 
(see  Appendix  D). 

When  faced  with  a  relatively  high  workload  task,  a  typical  tendency 
of  the  pilots  flying  the  Symbology  was  to  "fixate"  on  tracking  one  or  two 
of  the  commanded  flight  parameters  (to  the  detriment  of  the  remaining  param¬ 
eters).  An  example  of  this  observation  is  shown  in  Figure  5-4.  The  pilot 
was  commanded  to  roll-out  onto  a  new  course  and  immediately  de-accelerate 
end  climb  to  a  new  altitude.  The  pilot  was  to  maintain  a  given  flight 
path  angle.  In  this  case,  the  pilot  apparently  concentrated  on  intercepting 
the  new  course  line,  possibly  due  to  difficulties  in  establishing  the  preceding 
leg.  Meanwhile,  the  aircraft  was  slowly  descending,  when  in  fact  a  climb 
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Deviation  During  High  Pilot  Workload  Task 
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to  3000  should  have  commenced.  During  this  flight,  the  pilot  was  actually 
prompted  to  start  climbing. 


5.0.4  Non-linear  Course  Tracking 

"Standard"  symbology  display  formats  do  not  provide  for  the  presentation 
of  curved  or  non-linear  flight  paths.  Flight  plans  consist  of  connected 
straight  legs;  the  pilot  has  to  "round  off"  the  corners  by  executing  some 
manner  of  a  standard  turn.  Errors  in  determining  and  maintaining  the  correct 
bank  angle  result  in  a  horizontal  course  deviation.  Errors  of  this  nature 
are  typically  not  apparent  to  the  pilot  until  the  new  course  leg  is  (or 
is  not)  intercepted.  Problems  in  tracking  a  non-linear  flight  path  were 
most  apparent  during  the  180  degree  turn  portion  of  the  flight  plan  (Figure 
5-5).  Notice  that  the  pilot  did  not  show  the  same  degree  of  difficulty 
in  executing  the  turn  while  flying  the  CFPD  format. 
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Deviation  During  Non-Linear  Flight  Path  Tracking 


